On 2014-03-06 11:17, enrico franchi wrote:
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.
vi è del 76, I db relazionali sono fatti originare da un articolo di
Codd del 1970 (fonte: wikipedia).
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.
Postgres è un db decente: così tanto che potrebbe definire un timestamp
con una precisione superiore a quella che può gestire un applicativo.
Stai facendo un discorso da manuale (neanche tutti), io sto parlando in
termini pratici. La tupla (lettore, tag, timestamp) è univoca, certo
(nota: tag, non utente). È una buona chiave primaria? Tu hai letto dei
libri che dicono di sì. Io ho letto dei libri che dicono di sì e dei
libri che dicono di no. Ho scritto dei programmi ed ho la mia opinione,
che è no, per la componente casuale della precisione con cui ogni
sistema definisce i timestamp, perchè ogni url o form di ogni pagina web
che devo generare sarà più complessa, e perchè ogni join è un dito al
cubo (essendo tre i campi). E questo senza menzionare ORM non dico
"scritti coi piedi" ma semplicemente non overingegnerizzati. Che magari
non uso ora, ma in futuro chissà, e le basi di dati sono fatte per
*sopravvivere* al codice: il tuo programma fra 5 anni magari non lo
userà nessuno ma i dati che ha generato saranno un asset importante e
altri programmi, che non sai con che tecnologia verranno scritti, li
useranno.
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...
L'"employee id" è un mito che esiste solo negli esempi con cui si
scrivono gli articoli di database su come si fanno i join, non esiste
nella realtà. Non ho lavorato in nessuna azienda che avesse un
identificativo decente per tutti gli impiegati. Anche gli irregolari che
fanno pulizia di tanto in tanto, anche l'amante dell'amministratore
delegato che passa alla fine della riunione del consiglio di
amministrazione, hanno un badge. La cosa più simile all'employee id è
l'id sequenziale che il database gli ha assegnato quando è stato immesso
nel sistema la prima volta.
Il codice fiscale e' ovviamente una cattiva chiave (specie se non
supponi
di avere a che fare solo con italiani o residenti in italia).
Com'è che è così evidente in una ML amatoriale ma non per gli ingegneri
di Telecom? :)
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.
(peccato, citazione mancata :)
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.
Vabbè passiamo a bashare la cosa che tutti amano bashare (ancora,
spesso comicamente senza sapere quello che dicono e pensando di essere
depositari di chissà che conoscenza). Ora ci sarà anche il coretto di
tutti gli iscritti che la sanno lunga e "+1" e "haha che cretini"...
MySql non l'ha nominato nessuno, non stiamo parlando di database buoni o
cattivi qui. Io uso Postgres e una chiave primaria tripla con dentro un
valore reale la considero un'idea abbastanza cattiva da meritare una
chiave surrogata, sebbene il database sia perfettamente in grado di
gestirla. Tu no? Ok, ma sono opinioni, non oro colato: quello che pensi
non è giusto "in assoluto". Per te ha dei vantaggi. Che peraltro non hai
ancora elencato: hai solo detto "si fa così", ma questo è un dogma: non
è così che si insegna a "quelli che iniziano". Si elencano i pro e i
contro. Qual'è il vantaggio concreto di usare la tripla secondo te?
-- Daniele
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
