Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register

La Chiave

No, rimettetevi i pantaloni che non stiamo parlando di Tinto Brass.

Alura, un po' di tempo fa' $noicifacciamogliaffarituoi ha messo in piedi il solito sito interdet con CMS incorporato. Roba che oramai e' piu' comune del mal di testa che mi provocano. Dopo numerose bestemmie per via delle varie versioni del foxxuto sito che si incatastavano in continuazione e numerosi cicli di aggiorna, prova, riprova, downgrade, riprova, i pinguini si sono finalmente decisi ad accettare il mio suggerimento di mettere in piedi un sistema di testing basato su un singolo server (virtuale) che faccia sia da web server che da database server. Per i test dovrebbe essere piu' che sufficiente.

Ed infatti dopo un po' di verifiche e prove, la versione in 'test' viene spostata in produzione e sembra funzionare un pelo meglio. Il che significa che invece che inchiodarsi brutalmente e riportare due kili e mezzo di errori ad ogni pagina ne ritorna solo mezzo chilo.

Ma... Ma c'e' un "ma".

Il "ma" in questione e' che ci sono certe cose che funzionano in test e poi, una volta spostate in produzione, o non funzionano o danno dei risultati completamente diversi. Il che mi fa pensare che (come al solito) l'ambiente di 'test' non e' proprio uguale a quello di 'produzione'.

E non sto parlando del fatto che uno dei due ambienti e' composto da due macchine separate per web e db, ma del fatto che evidentemente l'applicazione e' diversa tra le due.

Dopo un altro po' di bestemmie, riesco a convincere i pinguini programmatroti che forse e' il caso di fare un bel dump del server di produzione e "spalmarlo" sul server di test, cosi' che si possa fare i test e verificare che i due ambienti rispondano nello stesso modo. Dopo aver fatto la "spalmatura" scopriamo che l'applicazione continua a rispondere in modo diverso. Ok, il problema e' evidentemnte nei dati del database. A questo punto, CL, membro della premiata ditta $pinguiniprogrammatrotisiamonoi, ha l'illuminazione: quando e' stata fatta l'installazione della nuova versione dell'applicazione e' stato anche caricato un database di prova senza prima zappare via quello esistente, il risultato e' che ci sono dei dati duplicati nel database e questi provocano i problemi.

IO - ...momento quajo'... dati duplicati? Nel database?
CL - Si', sicuramente... Possiamo fare un controllo con un "select questo-e-quello from..."

E la query ritorna 580 righe, mentre (secondo CL) dovrebbe ritornarne solo un terzo.

CL - Ecco il problema, abbiamo dei dati duplicati.
IO - Ma... come cappero si fa' ad inserire dei dati duplicati in un database? Non dovrebbero esserci delle chiavi primarie e cose cosi' per evitarlo?
CL - Huh? Chiavi primarie?

Il tono di CL mi fa' venire i brividi cosi' faccio un rapido controllo nel db e scopro che... Non ci sono chiavi primarie definite in nessuna tabella!!! E quindi non ci sono FK ne' altri meccanismi per forzare un minimo di "coerenza logica" dei dati. In effetti e' possibile inserire qualunque schifezza in questo database. Ed e' stato fatto.

IO - Ma non sarebbe meglio utilizzare una qualche constraint per evitare questi problemi? Voglio dire, come fate a mantenere la coerenza dei dati?
CL - Ah, ci pensa l'applicazione.

Ossignur... Ed il bello e' che questa gente usa Oracle! E lo usano come userebbero una merda come MySQLAccess! Non c'e' limite al peggio (come se non lo sapevo prima).

Davide
28/03/2011 08:00

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

26 messages this document does not accept new posts
Mauro Pietro By Mauro Pietro - posted 28/03/2011 08:43

<Ossignur... Ed il bello e' che questa gente usa Oracle! E lo usano come userebbero una merda come MySQLAccess!>

Non importa COSA usano ma COME lo usano per cui il risultato è sempre lo stesso.

Ciao BigD e buon inizio di settimana.

--
Mamo


Eladamri By Eladamri - posted 28/03/2011 08:46

Asd, meglio che non racconto il problema che ho avuto con un DB ultimamente... altrimenti vengo bannatocheeky

--
Eladamri


maxxfi By maxxfi - posted 28/03/2011 09:35

Roba che oramai e' piu' comune del mal di testa che mi provocano.

La prendo come una buona notizia che il rapporto nuovi siti interdet : mal di testa è minore di 1.

Pensavo peggio! :-P

--
maxxfi


Kim Allamandola By Kim Allamandola - posted 28/03/2011 09:36

Poi qualcuno mi critica quando dico che certe cose è meglio le facciano con

CouchDB&c che per lo meno fan meno casini (ed i restore sono un po' più

semplici)...

--
Kim Allamandola


Alberto By Alberto - posted 28/03/2011 10:30

A questo punto immagino che non usino neanche gli indici, così si risparmia anche la fatica di allocare spazio apposito per questi oggetti.

Tanto il database è Oracle, che avranno sicuramente scelto per le sue performance.

--
Alberto


Anonymous coward@ Alberto By Anonymous coward - posted 29/03/2011 17:35

Tanto il database è Oracle, che avranno sicuramente scelto per le sue performance.

Per poi accorgersi che nemmeno il povero Oracle è in grado di essere veloce se il DB è usato solo come data dump... ma allora compreranno sicuramente più dischi più veloci, più RAM e più processori...

 

--
Anonymous coward


Anonymous coward By Anonymous coward - posted 28/03/2011 10:50

Eh beh dai... anch'io uso una gru da 100 tonnellate come fermaporta... ma solo perchè ho una porta grossa.

--
Anonymous coward


Anonymous coward By Anonymous coward - posted 28/03/2011 10:57

non per dire ma Access supporta le chiavi esterne da almeno quindici anni...

devil

--
Anonymous coward


Messer franz By Messer franz - posted 28/03/2011 11:02

Rimetterci i pantaloni?E poi come faremmo a reinserire in loco le strutture sferiche rotolateci fuori dopo aver letto come hanno fatto il db?

 

In secondo luogo una precisazione da parte tua  : hanno fatto un db senza id e non verificano che da programma i dati (e allora sono fessi sì , ma come tanti altri - pensa ai tuoi yugoslavi) o hanno pure messo gli id e non li hanno dichiarati come primary key (e allora hanno raggiunto nuove vette dell'imbecillità)?*

 

*no , non sto dicendo che gli id sono indispensabili (anche se io sono in IDofilo)...chiedo solo se li hanno usati

 

 

Per concludere : secondo me usano oracle perchè perchè fa figo. Mi ricordo una ditta (anche abbastanza seria) che il capo (un programmatore VERO ma che non sapeva giudicare la gente) assunse un idiota per fare cose web (allora una novità e gli interessava esplorare il nuovo mercato) e lui gli fece comprare la licenza oracle per un sito per cui forse sarebbe bastato anche access prima versione per "motivi di immagine" (cioè , il sito e' una merda , va lento , e' fatto male ed appare male , ma , modestamente , usiamo oracle! Tra parentesi , aveva stragiurato al boss che per oracle bastava una macchina .... beh , diciamo "economica"...in pratica un 586 con un case nuovo...era il tipico "server supernuovo e potente pur evitando inutili sprechi e mantenedo i costi contenuti"..penso che ci siamo capiti... )

--
Messer franz


Riccardo Cagnasso By Riccardo Cagnasso - posted 28/03/2011 11:04

Io gli avrei sparato

--
Riccardo Cagnasso


Jamin-a By Jamin-a - posted 28/03/2011 11:05

Mado'... queste cose le so perfino io che ho fatto solo un corso sfigatissimo di "elementi di informatica" diretto a ingegnerichesioccupanodituttaltro.

--
Jamin-a


r3lative By r3lative - posted 28/03/2011 11:21

il fatto che oracle venga usato come access, ormai è lo standard. 

--
r3lative


Anonymous coward By Anonymous coward - posted 28/03/2011 12:23

Hai mai visto (mi rispondo: probabilmente si) la struttura SQL del modulo rlm_sql di FreeRADIUS? Da far accapponare la pelle.

 

Altro che PK e FK...

--
GCS/CM d- s:+: a--- C++ UL+++S E--- W+(-) N o+ w-- O? M- PS+ PE Y+ PGP t+(++) 5? X- R* tv- b++ DI+ D++++ G+ e h! r++ y++


Giulio By Giulio - posted 28/03/2011 12:27

Again, è stupendo vedere come la gente continui a sperperare soldi in applicazioni inutili. Per tabelle non costrette e senza chiavi, era più che sufficiente un MySQL con MyISAM (non voglio credere che le licenze Oracle e MySQL abbiano lo stesso prezzo).

Come dire... ci vuole saggezza anche per fare programmi ignoranti.

Per inciso, perché perdere 5 minuti a scrivere una chiave primaria e una FK, quando si può gonfiare una classe di controlli grossi ed error-prone? Senza contare il fatto che così non c'è alcun controllo sulle modifiche apportate direttamente con connessioni al db.

--
Giulio


Anonymous coward By Anonymous coward - posted 28/03/2011 13:46

Da dba devo dire che purtroppo, la cosa è molto diffusa. Non parlo solo di tutti quei maledetti CMS multidatabase che usano il db come fossero files piatti, ma anche di applicazioni che aziende pagano in soldoni e fanno schifezze incredibili.

Tabelle da centinaia di migliaia di record senza chiave primaria. Chiavi esterne? Non sanno cosa siano..

--
Anonymous coward


Sax By Sax - posted 28/03/2011 14:42

Al mio paese un detto dice "a ognuno il suo mestiere e al villano la carriola"

Mi sa che di gente che dovrebbe andare a spingere carriole ce n'è parecchia.

--
Sax


Other Anonymous coward By Other Anonymous coward - posted 28/03/2011 17:00

Schema E !!!!

Mai sentito parlarne ?!?!?!?!?! È la semplificazione dello schema ER (entità-relazione), usato dai programmatroti per snellire i loro impicci mentali.

Le relazioni sono inutili, le scrivo dentro la query.

--
Other Anonymous coward


ringo@ Other Anonymous coward By ringo - posted 29/03/2011 09:46

Le relazioni sono inutili, le scrivo dentro la query.



E soprattutto la query la compongo in runtime!

(parametri? prepare? che d'e'?)

E ogni tanto perfino il WHERE non si usa...

(ma no.... tiro fuori tutto e poi scandisco i record...)

--
ringo


R.P. By R.P. - posted 28/03/2011 20:15

Guarda che anche in Access ci sono le FK, e molti degli utenti che conosco io le usano.

Forse i pinguini sono peggio degli utenti Access...

--
R.P.


Anonymous coward By Anonymous coward - posted 28/03/2011 20:50

A dire il vero le PK hanno l'unico compito di identificare in modo univoco un record della tabella. L'unicità sui campi necessari dovrebbe essere garantita da constraint unique, anche perché di PK ce ne può essere una sola... e una PK con troppi campi a volte è troppo complessa da gestire (le FK dovrebbero sempre essere l'intera PK, non un subset...)

--
Anonymous coward


Andrea Ballarati@ Anonymous coward By Andrea Ballarati - posted 29/03/2011 09:09

A dire il vero le PK hanno l'unico compito di identificare in modo univoco un record della tabella. L'unicità sui campi necessari dovrebbe essere garantita da constraint unique, anche perché di PK ce ne può essere una sola... e una PK con troppi campi a volte è troppo complessa da gestire (le FK dovrebbero sempre essere l'intera PK, non un subset...)

 

Nella mia esperienza l'esistenza di campi con valore unico che non sono parte della PK è rara in un db correttamente progettato.

--
Andrea Ballarati


Anonymous coward@ Andrea Ballarati By Anonymous coward - posted 29/03/2011 17:30

Nella mia esperienza l'esistenza di campi con valore unico che non sono parte della PK è rara in un db correttamente progettato.

Dipende unicamente dal dominio dei dati. Mi è capitato di recente in una tabella dove un campo doveva essere univoco, ma modificabile (la PK è un'altra, ed è correttamente immutabile).

Tra l'altro okkio in Oracle alla semantica dei metadati "constraint unique" != "indice unique" (anche se il secondo può essere usato per gestire il primo, ma non necessariamente...), e per l'ottimizzatore cost-based la semantica è importante.

 

--
Anonymous coward


Andrea Ballarati@ Anonymous coward By Andrea Ballarati - posted 30/03/2011 09:09

Tra l'altro okkio in Oracle alla semantica dei metadati "constraint unique" != "indice unique" (anche se il secondo può essere usato per gestire il primo, ma non necessariamente...), e per l'ottimizzatore cost-based la semantica è importante.

E come farebbe Oracle a garantire il costraint unique senza costruire un indice?

 

 

--
Andrea Ballarati


Anonymous coward@ Andrea Ballarati By Anonymous coward - posted 31/03/2011 11:42

E come farebbe Oracle a garantire il costraint unique senza costruire un indice?

Non è detto che l'indice utilizzato sia unique (come specificato) . Se per qualche motivo esiste già un indice non unique utilizzabile per il constraint, Oracle può usare quello, senza crearne un altro. Dichiarare un constraint unique (e lasciare decidere a Oracle se creare un indice o no) può evitare di avere un indice ridondante da mantenere.

 

 

 

--
Anonymous coward


Andrea Ballarati@ Anonymous coward By Andrea Ballarati - posted 01/04/2011 15:27

Non è detto che l'indice utilizzato sia unique (come specificato) . Se per qualche motivo esiste già un indice non unique utilizzabile per il constraint, Oracle può usare quello, senza crearne un altro. Dichiarare un constraint unique (e lasciare decidere a Oracle se creare un indice o no) può evitare di avere un indice ridondante da mantenere.



Capisco quello che vuoi dire e sono d'accordo con te per quanto riguarda la semantica ma dal punto di vista di Oracle se esiste constraint unique -> esiste indice unico, questo volevo dire. Ultimo post sull'argomento per me onde evitare che il Bianchi mi passi sulla schiena con la moto :\)

 

 

--
Andrea Ballarati


Massimiliano By Massimiliano - posted 04/04/2011 16:12

Io pensavo di aver trovato l'unico DB senza PK/FK, ma a quanto pare...

--
Massimiliano


26 messages this document does not accept new posts

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira