Newsgroup: it.comp.software.database
Titolo: Dubbio su database design: singola tabella vs multi tabella

Ciao a tutti, mi trovo a dover progettare un database (postgres) che
conterrà diversi tipi di documenti e vorrei un consiglio dalla
comunità.
 
Ogni tipo di documento dovrà avere i suoi campi propri, ad esempio:
 
Documento Appuntamento: id, id_cliente, data appuntamento, ora
appuntamento, indirizzo, note
Documento Preventivo: id, id_cliente, data preventivo, data scadenza
preventivo, pagamento concordato, prezzo, etc..
 
La stima di campi per ogni documento va da un minimo di 4 a un massimo
(teorico) di 40/50.
 
La creazione di nuovi tipi di documento, e l'aggiunta/eliminazione/
modifica dei campi deve avvenire dinamicamente on-the-fly
(l'applicativo gestisce la cosa)...
 
A spanne, devo prevedere che ogni tipo di documento sarà modificato
1-2 volte l'anno (con l'aggiunta di campii)
 
Il mio dubbio è come strutturare il database, a mio avviso le
soluzioni sono 3:
 
1. Singola* tabella per ogni tipo di documento
2. Una tabella padre per ogni tipo di documento, più una tabella per
tutti i campi aggiuntivi
3. Una tabella padre per ogni tipo di documento, più una tabella per
ogni campo aggiuntivo
 
La prima soluzione è la più semplice e, a livello di performance, la
più veloce, tuttavia comporta che l'aggiunta di una nuova colonna su
tabella già popolata con diversi record richiederebbe un lock&freeze
della tabella che potrebbe causare problemi.
 
La soluzione 2 comporta, per ogni select, di fare n° join con la
tabella che contiene i campi e, inoltre, tutti i campi andrebbero
salvati sullo stesso tipo di colonna.. insomma un poccio, questa la
scarto a priori.
 
La soluzione 3, dove ogni campo ha la sua tabella a 3 campi (id,
id_padre, valore) è simile alla soluzione 2 solo che viene rispettato
il tipo di colonna.
 
 
Ho fatto qualche test e io sarei per la soluzione 1, le performance in
insert/select/update sono abissali tra la soluzione 1 e la soluzione
3, specialmente se lavoriamo sotto foreign keys per garantire la
refenzialità dei dati (che potrebbe anche essere gestita a livello
codice).
 
Tuttavia ho notato che molti CMS utilizzano la soluzione 3 (drupal ad
esempio), altri ancora la soluzione 2 mista alla 3 (wordpress)... non
ho ancora visto la soluzione 1 utilizzata in un progetto esistente.
 
 
Voi cosa ne pensate?
Quali sono i pro e i contro che non ho valutato delle 3 soluzioni?

 Quali sono i pro e i contro che non ho valutato delle 3 soluzioni?
 
La soluzione uno sembrerebbe sicuramente la più pulita.
Va considerata però anche la quantità di dati che vai a maneggiare.
 
C'è una quarta soluzione che ti consiglio di prendere in
considerazione, e sono le tabelle derivate (inherit), che ti
permettono un approccio simile al terzo, ma con i vantaggi di gestire
una sola tabella per quanto riguarda riepiloghi, cancellazioni e via
dicendo (stai solo attento ai vincoli di integrità e trigger che non
si ereditano).
Ho applicato con successo questa soluzione per cataloghi prodotti.
Sicuramente il db non sarà portabile su altri rdbms, ma i vantaggi
sono grandi.
 
Lucazeo.

 
 
 
con un vagone di se, voterei per la soluzione 1.
 
pero', ovviamente, dipende...
 
quale e' l'ambito di utilizzo di tutto cio'?
hai dei vincoli di performance/caratteristiche/salsignorecos'altro che 
potrebbero indirizzare le tue scelte?
esiste una 'gerarchia' tra i tipi di documento?
di che numeri si parla?
quanti documenti?
quanti tipi?
 
-- 
Paolo opg
 
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 Ogni tipo di documento dovrà avere i suoi campi propri,
 
Hai saltato la descrizione del problema.