Giovanni Porcari: > Laddove non ci sia una chiave naturale assolutamente univoca e immutabile, > (ad esempio in una tabella di elementi la chiave 'K' identifica benissimo > il potassio)noi usiamo sempre un id di 22 caratteri univoco basato su uuid. > La ragione per cui non usiamo un seriale è che nel caso si debbano unire i > dati di tabelle provenienti da sistemi diversi la probabilità di avere > duplicati è irrisoria. Nel caso invece di un serial si è costretti a > assegnare nuovamente l'id ai record importati e se l'import riguarda anche > tabelle in relazione il problema non è banalissimo. > Non credo che in termini di velocità sulle macchine moderne le prestazioni > per accedere ad un btree siano in qualche modo un problema mentre la > trasportabilità dei grappoli di tabelle è un vantaggio notevole. >
ottima tecnica, prevenire è meglio che curare :-) però per le performance... non sono d'accordo gli interi sono più rapidi e quando hai (migliaia di) milioni di record te ne accorgi. Per chi diceva chiave naturale è sempre meglio di un intero, NI. Il codice fiscale è l'esempio. Usato per i dipendenti, è sbagliato. Usato per le persone fisiche, ok. Ma come prevenire un inserimento errato? capita capita, soprattutto per quelli che sono hanno il CF come eccezione, poi va a ripristinare un codice fiscale sbagliato in un db complesso :-) PS ma matricola del dipendente come chiave dei dipendenti? se fosse una sola azienda forse, ma se poi per qualche ragione si dovesse ripartire con la numerazione? ok p probabile che debba cambiare anche l'azienda.... o mio dio ce ne scampi e liberi.. per essere liberi la chiave non deve centrare nulla con il business. Perché tutto quello che credevi di sapere, "sallo" che non lo sai. :-)
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python