Le migliori pratiche quando si gestiscono molte colonne vuote della tabella?

1

Ho uno schema che consente più tipi di post nel mio progetto Django (un po 'come Tumblr). Gli utenti possono creare post di diversi tipi. Uno di questi tipi è una foto, per cui voglio i dati EXIF.

Se ho una tabella super generalizzata, ha senso creare colonne aggiuntive per i dati exif? Ciò comporterebbe un sacco di colonne vuote per ogni tipo di post che non è Photo.

In alternativa, avrebbe senso creare un modello separato per le foto completamente e creare invece una chiave esterna per il modello Post?

    
posta ang 06.09.2013 - 01:42
fonte

1 risposta

2

Ciò a cui si sta fondamentalmente riferendo è la modellizzazione dell'ereditarietà in un database. Puoi trovare questa risposta su Stack Overflow utile. Ci sono alcune altre domande simili risposte in modo simile anche lì.

In termini di scelta di quale delle 3 opzioni seguire, ci sono un paio di fattori che penso che troveresti importanti. Direi che la prima considerazione è solo quante proprietà hanno i tuoi post in comune. Se sono molti tipi, tutti al 90% lo stesso, probabilmente non vuoi una tabella per calcestruzzo (TPC).

Successivamente, considererei quale dei modelli è supportato correttamente dall'ORM django. Non vuoi scegliere la più pura soluzione da una prospettiva di database relazionale, che diventa terribile da usare a causa delle limitazioni del tuo livello dati.

La mia tendenza sarebbe quella di andare a un tavolo per tipo, ma la maggior parte del mio tempo è impiegata senza ORM "moderno" e l'ottimizzazione del mio schema è importante. Probabilmente avrà il risultato di rendere le query più complesse. Questo approccio implica il tuo suggerimento di creare una chiave esterna in una tabella aggiuntiva.

    
risposta data 06.09.2013 - 02:21
fonte

Leggi altre domande sui tag