scusate posso intervenire ?
Inviato da : Ernesto Luciano Trespidi email: keple...@hotmail.com Tel: 3299255463 Il giorno 06/mar/2014, alle ore 12:18, "enrico franchi" <enrico.fran...@gmail.com> ha scritto: 2014-03-05 18:46 GMT+00:00 Daniele Varrazzo <p...@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@lists.python.it http://lists.python.it/mailman/listinfo/python
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
