««« | »»»
Chiavi Composite
Questo post è il classico esempio dell’eterna diatriba su quale sia il miglior tipo di chiave da usare in un database, in questo caso con l’aggiunta della variante sulle chiavi composite e dalla prospettiva dell’applicazione.
A mio parere il problema del post – non ho letto i commenti – è che semplifica troppo la questione, non tenendo conto dei difetti della soluzione con chiavi sintetiche (o surrogate).
Il punto da cui partire è: cosa significano le chiavi composite? Beh, ci danno un’informazione riguardo ai vincoli d’integrità del database. Ad es. date due tabelle, “Utenti” e “Gruppi” e una tabella di join, la chiave composita sulla tabella di join, formata dalle chiavi primarie di “Gruppi” e “Utenti” ci dice un utente non può – ovviamente – appartenere due volte allo stesso gruppo. Anche se usassimo una chiave primaria surrogata, questo vincolo deve rimanere comunque e per farlo rispettare ci sarà presumibilmente bisogno di un ulteriore indice sulle due foreign keys.
Insomma, se è vero che le chiavi composte sono meno “maneggevoli”, bisogna anche ricordare qual’è il prezzo da pagare per le soluzioni alternative. Aggiungo anche che framework come l’EOF rendono molto semplice lavorare con queste configurazioni.
C’è un solo caso, comunque piuttosto frequente in design normalizzati, in cui userei una chiave sintetica e si presenta nel momento in cui ci sono delle foreign key che puntano alla chiave primaria composta. In questa situazione usare tutti i componenti della chiave primaria per creare il vincolo d’integrità diventa rapidamente impraticabile. Dev’essere però chiaro che si tratta di una necessità pratica e non di modellazione.
Per proseguire
Commenti e trackback sono disabilitati.