Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | 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

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

26 messaggi this document does not accept new posts

Mauro Pietro

Di Mauro Pietro postato il 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

Di Eladamri postato il 28/03/2011 08:46

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

-- Eladamri

maxxfi

Di maxxfi postato il 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

Di Kim Allamandola postato il 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

Di Alberto postato il 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 Di Anonymous coward postato il 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

Di Anonymous coward postato il 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

Di Anonymous coward postato il 28/03/2011 10:57

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

devil

-- Anonymous coward

Messer franz

Di Messer franz postato il 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

Di Riccardo Cagnasso postato il 28/03/2011 11:04

Io gli avrei sparato

-- Riccardo Cagnasso

Jamin-a

Di Jamin-a postato il 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

Di r3lative postato il 28/03/2011 11:21

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

-- r3lative

Anonymous coward

Di Anonymous coward postato il 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

Di Giulio postato il 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

Di Anonymous coward postato il 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

Di Sax postato il 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

Di Other Anonymous coward postato il 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 Di ringo postato il 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.

Di R.P. postato il 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

Di Anonymous coward postato il 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 Di Andrea Ballarati postato il 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 Di Anonymous coward postato il 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 Di Andrea Ballarati postato il 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 Di Anonymous coward postato il 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 Di Andrea Ballarati postato il 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

Di Massimiliano postato il 04/04/2011 16:12

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

-- Massimiliano

26 messaggi this document does not accept new posts

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira