Newsgroup: it.comp.software.database
Titolo: struttura elementare db

ciao a tutti, durante la progettazione di un db mi sono reso conto che,
forse, la soluzione che stavo scegliendo poteva non essere la piu'
indicata, quindi ho provato a semplificare il problema per poter
ricevere un consiglio da chi, magari, ci ha gia' sbattuto la testa.
in pratica:
ho un database con una tabella per ogni entita': (struttura attuale)
A (ida char(22), nomea varchar(30), ...)
B (idb char(22), nomeb varchar(30), ...)
C (idc char(22), nomec varchar(30), ...)
per ogni record di tutte le tabelle entita', devo poter inserire un
numero imprecisato di annotazioni che memorizzo in una tabella
apposita:
NOTE (idnota char(22), annotazione varchar(100))
in questo momento, sto associando ogni nota all'oggetto a cui
appartiene,
tramite diverse tabelle, una per ogni entita'
NOTEA (idna char(22), ida char(22), idnota char(22))
NOTEB (idnb char(22), idb char(22), idnota char(22))
NOTEC (idnc char(22), idc char(22), idnota char(22))
preciso, inoltre, che:
-le entita', sono attualmente circa 3.000
 (sommando il numero di record di tutte le tabelle)
 e non supereranno le 10/20.000 anche
 considerando un tempo di 20 anni di utilizzo
 del software
-per ogni entita' (per ogni record), le annotazioni
 saranno, verosimilmente, max 20 all'anno
altre info, che dovrebbero pero' essere piu' o meno ininfuenti, sono:
-il db e' su firebird
-tutti gli id (globalmente univoci) vengono generati da una funzione
sul db,
 tramite trigger, ogni volta che viene inserito un nuovo record
-le chiavi primarie sono sempre gli id univoci e non hanno mai un
significato
 nella struttura degli oggetti rappresentati dal db
-non ho specificato quali siano, di volta in volta, le FK, in quanto
credo che
 sia abbastanza evidente (hanno sempre lo stesso nome sulle diverse
tabelle)
adesso mi sono posto il problema:
e' la struttura "migliore" ?
quali altre possibilita' ho e con quali vantaggi/svantaggi?
possibili alternative che mi sonon venute in mente, sono:
-prima possibilita' (struttura 1)
tabelle entita':
A (ida char(22), nomea varchar(30), ...)
B (idb char(22), nomeb varchar(30), ...)
C (idc char(22), nomec varchar(30), ...)
tabella annotazioni:
NOTE (idnota char(22), idtipoent integer, ident char(22), annotazione
varchar(100))
tabella di decodifica:
CODENT (idce char(22), idtipoent integer, tipoentita varchar(30))
-seconda possibilita' (struttura 2)
tabelle entita':
A (ida char(22), nomea varchar(30), ...)
B (idb char(22), nomeb varchar(30), ...)
C (idc char(22), nomec varchar(30), ...)
tabelle annotazioni:
NOTEA (idna char(22), ida char(22), annotazione varchar(100))
NOTEB (idnb char(22), idb char(22), annotazione varchar(100))
NOTEC (idnc char(22), idc char(22), annotazione varchar(100))
quale vi pare la soluzione piu' sensata, ordinata, efficiente etc. ?
ciao e grazie
cristiano

 quale vi pare la soluzione piu' sensata, ordinata, efficiente etc. ?
Stai facendo il cosiddetto physical modeling, per cui a ciascuno
dei criteri che hai menzionato potrà corrispondere un design diverso,
e alla fine conterà molto il gusto personale.
Se invece vogliamo dare credito al modello relazionale, bisogna
cominciare dalle definizioni di entità, chiave primaria, integrità
referenziale, riga vs. record etc... per poi cominciare ad esporre
lo schema concettuale, senza il quale nulla si può dire della
correttezza di un db.

 quale vi pare la soluzione piu' sensata, ordinata, efficiente etc. ?
ciao.
La seconda e' sicuramente meglio per quanto riguarda l'integrita' 
referenziale che si mette attraverso delle semplici foreign key:
NOTEA.ida --> A.ida
NOTEA.idb --> A.idb
NOTEA.idc --> A.idc
Per metterla nel primo caso devi metter su un accrocchio per
il fatto che hai un campo che ti identifica la tabella. Non riesci
a farlo con delle semplici foreign key e devi usare trigger o
gestire da applicazione client.
Inoltre se le entita' stanno su tabelle separate puo' essere piu'
corretto anche pensare che le annotazioni siano entita' separate
e quindi su tabelle separate. Se in futuro oltre ad annotazione
ti serve aggiungere un campo in piu' solo per un'entita' (che so,
una data di validita dell'annotazione) lo fai solo dove serve.
Se ti serve avere tutte le annotazioni insieme le puoi sempre
ottenere con una vista.
Inoltre il fatto di avere tabelle piu' piccole dovrebbe rendere
le query leggermente piu' performanti rispetto ad una sola tabella 
grande, ma questo dipende molto dal server, non conosco nello specifico 
firebird quindi potrei sbagliare!
ciao
Giacomo