[Python] info su db

[enrico franchi]

2014-03-05 18:46 GMT+00:00 Daniele Varrazzo <piro a develer.com>:


> Questa guerra di religione è probabilmente più vecchia sia di Emacs che di
> Vi :)
>

Ah, direi di no! I db relazionali sono relativamente recenti, almeno
rispetto a vi.


>
> 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).
>

Il timestamp da solo, si. E' ovviamente non univoco (posso ampiamente avere
due accessi allo stesso momento).
Comunque se hai un db decente, puoi usare i tipi di dato appropriati.


> 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...


E infatti io non parlavo di codice fiscale. Parlavo di employee ID, che per
una serie di cose e' qualcosa che e' semanticamente significativo nel
dominio applicativo.
Non e' solo un artefatto del database...

Il codice fiscale e' ovviamente una cattiva chiave (specie se non supponi
di avere a che fare solo con italiani o residenti in italia).



> 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.
>

Ma in questo caso una chiave e' ovvia. In un singolo istante, per un
singolo lettore, puoi avere solo una lettura. Se pensi di non avere letture
abbastanza granulari, puoi avere al limite anche la persona che ha badgato.


> 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? :)


Non e' questione di vincere. E non ci siamo solo noi. Ci sono anche quelli
che iniziano: per queste persone e' forse una buona cosa sapere che se e'
vero che MySQL supporta(va) il modello relazionale in modo tragicomico,
questo non vuole dire che bisogna pensare il db con uno schema errato per
forza: si puo' usare una tecnologia che lavora bene.

-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140306/c34da543/attachment.html>