[MontelLUG] A proposito di SQL e database - domanda inerente al corso di SQLite
Marco De Paoli
depaolim a gmail.com
Gio 25 Set 2014 16:57:21 CEST
ciao Davide,
Il 25 settembre 2014 16:26, Davide Posillipo <dav.posillipo a gmail.com>
ha scritto:
> Buongiorno a tutti,
>
> sto cercando di realizzare una base di dati relazionale a partire da un
> modello ER che ho man mano ridotto eliminando entità e relazioni che mi
> sembravano ridondanti.
>
> Ora che sto traducendo il tutto in termini di relazioni (tabelle), mi sono
> accorto che una di queste relazioni ha come chiave primaria una chiave
> composta da quattro attributi.
>
> La mia domanda è: avere relazioni con chiavi primarie composte da diversi
> attributi potenzialmente può portare a situazioni problematiche? Qual è, se
> esiste, un compromesso accettabile tra numero di relazioni e non ridondanza
> delle informazioni (senza ricorrere alle forme normali)?
in linea di massima ti direi che dipende da un sacco di cose
il tipo di questi campi? i valori, una volta caricati, sono veramente
scolpiti nella roccia oppure potrebbero cambiare? come accedi alla
base dati? direttamente in SQL oppure usi un ORM? l'ORM ha dei limiti?
(es. vuole solo chiavi singole? ce ne sono ce ne sono...)
io per esempio tendo a definire una singola chiave primaria id di tipo
integer e ottenere in questo modo criteri di join e foreign key puliti
puliti
ovvio che poi se voglio un vincolo di unicità su una tupla composta da
più campi mettero un constraint unique sulla combinazione dei campi
(a quel punto ti creerà anche un indice unique che quindi ti velocizza
le ricerche con quel criterio)
certo ti ritroverai con due indici (la chiave primaria più lo unique)
quando potresti averne uno solo...
ok, ma con il costo moderno degli storage non è un grosso problema
mi potresti obiettare che due indici significa anche doppio
aggiornamento in caso di insert/update. Ok, ma anche le i cicli di
clock delle CPU non costano poi così tanto ;-)
perchè soprattutto, se effettivamente i valori dei campi in chiave
possono modificarsi nella "storia" del record
tanto più se sono più di uno
Beh, il fatto di tenere consistenti le foreign key sarà una cosa che
ti devi smazzare tu da logica applicativa, mentre invece se sono
collegati per id sono legati per sempre e non ci pensi più
insomma torniamo alla mia osservazione iniziale: dipende
certo, se stiamo parlando di centiania di milioni di record magari la
cosa ha il suo impatto... parliamone
just my 2 c
>
> Grazie per l'attenzione,
de nada,
a proposito, non credo di aver ancora mai partecipato attivamente alla lista
per cui ... ciao a tutti!
Marco
More information about the montellug
mailing list