[Python] info su db

[Daniele Varrazzo]

On 2014-03-05 17:05, enrico franchi wrote:
> 2014-03-05 16:21 GMT+00:00 Daniele Varrazzo <piro a 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