Newsgroup: it.comp.software.database
Titolo: Suggerimento di progettazione

Salve a tutti,
devo realizzare un DB che contenga informazioni classificate per
comune, provincia e regione. A tal fine mi chiedo quale sia la
soluzione ideale per le tabelle relative appunto a comuni, provincie e
regioni.
Mi spiego: potrei realizzare 3 tabelle:
REGIONI( CodReg, NomeReg )
PROVINCIE( CodReg, NomeProv, CodProv )
COMUNI( CodProv, NomeCom, CodCom )
e la/le tabella/e con le informazioni da gestire:
INFORMAZIONI( CodCom, ... altri campi ... )
In questo modo potrei aggregare le informazioni mettendo in join le 3
tabelle:
REGIONI.CodReg in join con PROVINCIE.CodReg
PROVINCIE.CodProv in join con COMUNI.CodProv
INFORMAZIONI.CodCom join COMUNI.CodCom
La soluzione alternativa potrebbe essere di fare una "tabellona":
COMUNI( NomeReg, NomeProv, NomeCom, CodCom )
e un solo join (l'ultimo tra i 3 precedentemente proposti)
Mi chiedo (e gentilmente vi chiedo) quale sia la scelta progettuale
più conveniente.
In termini di ottimizzazione e velocità di esecuzione la seconda
scelta sembrerebbe migliore perchè condensa tutto in una sola tabella,
per quanto ridondante (la teoria della normalizzazione prescriverebbe
che solo la chiave primaria di una certa tabella vada ripetuta in
un'altra tabella contenente informazioni correlate alla prima, in
questo caso sia "nome" che "codice" potrebbero essere chiavi primarie,
ma "codice" sarebbe più breve e quindi più conveniente... però
andrebbe ripetuto più volte in 3 tabelle diverse, con spreco di
spazio)... inoltre avendo 3 tabelle, nelle query per aggregare i dati
dovrei fare numerosi e costosi join...
Che ne pensate? Che soluzione adottereste?
Grazie a tutti per l'attenzione e per le risposte!
Simone.

 pi� conveniente.
Io di solito prediligo la "pulizia" del DB, quindi nel tuo caso
preferirei creare tre tabelle distinte per memorizzare cose distinte
evitando dipendenze parziali tra gli attributi.
Inoltre se per caso un domani dovessi aggiungere una nuova colonna
che so alle regioni, dovresti replicare questa informazione su tutte
le righe della "tabellona" relative a quella regioen: uno spreco
di spazio e di tempo!
Naturalmente quando poi ti serve la "tabellona" basta fare una vista.
In  termini di performance direi che non dovresti avere differenze
significative, anche se dipende sempre da che DB stai usando da quali
indici metti alle tabelle e da come sono fatte le query di accesso.
ciao
Giacomo

 query per aggregare i dati dovrei fare numerosi e costosi join...
Non e` detto che sia sempre piu` lento. Anche la memoria ha un costo,
ed avere tabelle piu` piccole ha dei vantaggi prestazionali quando
la memoria si satura (migliore caching).
Inoltre, sara` piu` veloce solo per ALCUNE query, ma piu` lento
per altre. La soluzione con le tabelle completamente normalizzate
avra` un comportamento maggiormente omogeneo nei confronti di
query impreviste. 

 di spazio e di tempo!
Questo fattore da solo secondo me e` sufficiente per favorire
la soluzione normalizzata. 


Sono d'accordo! Si fa presto a sottovalutare i rischi: sembra solo
un campetto replicato, "basta fare un'update ogni volta"... e poi
ci si ritrova come niente con le righe tutte incoerenti! :D
ciao
Giacomo

On 16 Mag, 02:18, Giacomo Degli Esposti

Grazie per le preziosissime risposte e i preziosissimi suggerimenti!
Credo proprio che adotterò la soluzione delle 3 tabelle in join... più
pulizia del DB, più versatilità, costo computazionale contenuto...
Per la cronaca utilizzo MySQL sotto Linux.
Ciao, a presto!