Come diceva un utente ieri sera, la notte ha portato consiglio!
E' noto che i criteri di normalizzazione dei database servono per assicurarne l'integrità di dati, evitarne ridondanze e mantenere prestazioni elevate. Di conseguenza un sistema ben progettato non dovrebbe prescindere da esse, ed anzi rispettarle quanto più possibile. Personalmente, sto cercando di "spingermi" sino alla terza forma normale e sono impattato in una apparente contraddizione in merito alla quale sono a chiedervi lumi.
1. In una tabella vanno evitate ridondanze; se un campo potrebbe evitarsi in quanto le sue veci sono già svolte da uno o più campi tra i rimanenti, non ci sono buone ragioni per mantenere quel campo superfluo che appesantisce inutilmente la struttura della tabella.
2. E' buona norma tenere in ogni tabella una chiave id autoincrementale da candidare a chiave primaria, in modo da sfruttare il suo tipo numerico per rendere più veloci le ricerche ed in generale le operazioni.
Bene, quando una tabella possiede una coppia di valori integer che già di per sé presi in coppia saranno sempre univoci, vale la pena aggiungere un ulteriore campo, appunto un id autoincrementale, che diventerà la chiave primaria della tabella? Io direi di sì, anche a 'logica' si capisce subito, in questo modo, che si migliorano le prestazioni. Però, in questo modo, si aggiunge un campo che in fondo sarebbe superfluo rispetto agli altri, violando in apparenza le regole sulla normalizzazione. Quindi... Meglio aggiungerlo o no? Possibile che aggiungendo quell'id tali norme siano violate? A me pare stranissimo. Un conto è sconsigliare l'aggiunta di un campo quando la sua funzione è puramente informativa (ad esempio aggiungere il campo "nomeprovincia" quando ho già il campo "siglaprovincia"), un conto è aggiungere un campo per fargli svolgere una funzione ben precisa, come quella di una chiave primaria. Che ne dite? Sicuri che aggiungendo quell'id io debba violare tali regole?
Rispondi quotando
)