[Python] Applicazione WEB con Python e Postgresql

[Simone Federici]

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. :-)
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140924/d757695e/attachment.html>