[Python] info su db

[Luciano Trespidi]

scusate posso intervenire ?



Inviato da :
Ernesto Luciano Trespidi
email: keplero1 a hotmail.com
Tel: 3299255463


Il giorno 06/mar/2014, alle ore 12:18, "enrico franchi" <enrico.franchi a gmail.com> ha scritto:




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-
_______________________________________________
Python mailing list
Python a lists.python.it
http://lists.python.it/mailman/listinfo/python
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140306/bb442754/attachment.html>
-------------- parte successiva --------------
_______________________________________________
Python mailing list
Python a lists.python.it
http://lists.python.it/mailman/listinfo/python