linux user group brescia

On Fri, Aug 04, 2006 at 01:19:15AM +0200, Andrea Gelmini wrote:
> inoltre, non ho capito il tono della mail. sembra tu voglia biasimare il
> tipo, che per altro ha dato delle risposte precise.
> tu invece non sei andato oltre al solito lamento e a qualche
> considerazione tipica di chi non ha mai lavorato in ambienti di
> produzione. 

qualcuno si è lamentato dicendo che il mio reply fosse troppo duro...
provero' allora a riformulare le mie affermazioni in un modo piu`
gentile/proficuo, tosto che non mi interessa prendere le difese di
mysql:

a) non *esiste* database relazionale, commerciale o meno, che non sia
incorso in problematiche come quelle citate, tra una release e l'altra;
b) non *esiste* database relazionale che possa garantire la stessa
risposta alla stessa query tra una release e l'altra (non fatemi
scrivere mille incisi, che ci siamo intesi);
c) non *esiste* database relazionale che implementi tutte le specifiche
SQL, e che onori in senso stretto tutte quelle implementate.

questo, ovviamente, non perchè i programmatori siano stupidi, e debbano
attendere quelli del LugBS per imparare a programmare, o perchè siano
stronzi (tutte le rotture di compatibilita` sono tipicamente fatte, in
questi casi, obtorto collo), ma perché:

a) le specifiche SQL lasciano numerose zone d'ombra (alcune risolvibili
con un po' di buon senso, altre non risolvibili del tutto);[1]
b) e per il punto di cui sopra, e per il fatto che scrivere un planner
di un RDBM efficiente/completo è un lavoro fottutamente complesso/lungo,
ci si puo' accorgere solo dopo un mucchio di tempo che i risultati della
query non siano corretti,[2] rispetto alle specifiche. parlo di casi
concreti che accadono/sono accaduti a sistemi che vanno da oracle a
postgresql;

insomma, la morale di tutto 'sto pistolotto è che è ora di finirla di
dare la caccia al *miglior database*. tranquilli, non esiste.
esistono un fottio di motori, pero', che cercano di risolvere tipologie
differenti di problematiche, offrendo una lingua, al programmatore, piu`
o meno franca, come lo SQL.

il vero dramma è continuare ad avere a che fare con sviluppatori che 
continuano ad infilare tutto in una logica relazione quando sarebbe piu`
efficiente ragionare per record (tipo berkeley db), oppure in xml (vedi
sempre sleepycat), o ancora in modo testo (/rdb, nosql).

la fuori non abbiamo la miglior automobile in giro, unico modello
prodotto in tutto il mondo, ma abbiamo un fottio di automezzi, e una
manica di rimbambiti tutti uguali che parcheggiano in doppia fila sia
con i SUV che con le Panda.

la prossima volta che ci incontriamo ti offro una birra, sergio, così,
se te la sei presa, ti ubriachi e te la dimentichi...

mi viene chiesto perchè non me la sia presa con il ghido... bhe, il suo
fondamentalmente era un sfogo (oltre al fatto che, come lui, non leggo
cio' che scrive da anni ormai). il problema stava, a mio avviso, nel non
cadere nella trappola del ragionamento.

ciao,
gelma


----------
[1] vogliamo discutere della funzione, banale a prima vista, length()?
mi deve tornare la lunghezza di una stringa. ma non viene indicato se
debba essere tornato, al client, il numero di byte della stringa o il numero di
caratteri. se pensi che questi debbano sempre coincidere, prova a
pensare ai caratteri a 2 byte (unicode et similia).
[2] tanto per rimanere in tema di stringhe, parliamo di order by,
applicato al set standard ASCII. l'algoritmo sembrerebbe quasi banale,
se non fosse che ad un certo punto salta fuori che, in talune parole
turche, la lettera 'I' è scritta maiuscola, ma ha valore minuscolo.
postgresql ha, ovviamente, dovuto correggere il comportamento, da una
release con l'altra.