[Python] info su db

[Daniele Varrazzo]

On 2014-03-06 11:17, enrico franchi wrote:
> 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.

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