On 2014-03-05 17:05, enrico franchi wrote:
2014-03-05 16:21 GMT+00:00 Daniele Varrazzo <p...@develer.com>:
Utente: id, nome, cognome, indirizzo ecc..
Tag: id (del db, forse non necessario), identificativo (quello che il
lettore legge), emesso il, ritirato il, motivo del ritiro ecc.
Utente per tag: quale utente, quale tag, da quando l'ha avuto, fino a
quando l'ha avuto.
Lettura: id, quale tag, quale lettore, a che ora.
Presenza: id lettura in, id lettura out.
Lettore: id, ...tutte le informazioni che servono
Io andrei piano con tutti questi id. Quando c'e' un ID naturale,
niente da
dire (e.g., employee id).
Pero' mettere gli ID per non usare chiavi primarie "vere", non mi
piace
tanto. Tipicamente un evento di lettura e' verosimilmente
identificato
univocamente da utente, ora, verosimilmente quale lettore lo ha
fatto.
Questa guerra di religione è probabilmente più vecchia sia di Emacs che
di Vi :)
La penso come te: se vedi nei miei esempi ho dato un forse a mettere
l'id su un tag. Non conosco la tecnologia, ma probabilmente
l'identificativo pubblico è sufficiente.
Ma il resto no: la tupla (id tag, id lettore, timestamp) non è pratica
come chiave di una Lettura. Hai già bisogno di 6 campi per linkare due
letture ad una Presenza, in più un timestamp è (praticamente) un valore
reale, non discreto, e si presta male come identificativo (magari in
postgres ha un numero di usec intero, poi passa attraverso python che lo
converte in virgola mobile, fai una seconda query e ci scappa un
arrotondamento di un milionesimo di secondo che te lo fa mancare).
Sono favorevoli alle chiavi naturali, ma quando siano *veramente*
univoche. Il che è più raro di quello che sembra. Una targa non
identifica abbastanza bene un'auto (come feci in uno dei primi programmi
che scrissi, e i venditori si sovrascrivevano a vicenda le auto da
rendere nei preventivi, perché quando il cliente non ricordava a memoria
la targa scrivevano tutti "NON"...). Non sono neanche univoche, come
sanno quelli con targa "CD ... .." che beccano le multe al posto di
quelli del Corpo Diplomatico (che sono uguali ma scritte in blu...). Un
codice fiscale non identifica abbastanza bene una persona: puoi non
conoscerlo, può non averlo... Allo stesso modo sono favorevole alle
chiavi multiple, ma quando siano pratiche: in una tabella di unione
molti-a-molti non ho problemi ad usare la coppia di pkey come pkey, ma
non butto il sangue a cercarne una quando non è ovvia.
Chiavi naturali/surrogate e chiavi singole/multiple sono battaglie già
combattute e di cui si sa che non c'è vincitore. Che ne dici di una
bella partita a scacchi? :)
-- Daniele
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
