Tales from the Machine Room |
Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register
Magari tali bacherozzi sono stati corretti, ma DB ha scoperto sulla sua pelle che altri bacherozzi sono stati aggiunti. In particolare uno che affligge (indovina un po') la funzione di "importazione" dati.
Se a questo aggiungiamo che il database e' progettato con una qualche parte del corpo che non ha assolutamente niente a che vedere con la testa, capiamo immediatamente che ci sono dei seri problemi.
Il paguro che ha progettato il database evidentemente e' un convinto sostenitore del partito del "Chiavi Primarie Autogenerate Forever", dato che ogni singola foxxuta tabella ne ha una. Io (ovviamente) sono un convinto sostenitore del partito opposto. Prendiamo per esempio la gioia di questa fetecchia. C'e' una tabella "Teams", che e' usata per raggruppare gli utenti in "team" (che vi aspettavate?). La tabella e' composta da id, descrizione ed altra roba. Ora, ovviamente la "descrizione" e' univoca nella tabella (senno' come potresti distinguerli?), il che porta automaticamente alla domanda "che ci sta a fare l'id in quella tabella?". Almeno porta me a fare la domanda.
Tu! Si Tu! Tu con la tastiera! Prima di sparare quel commento che dice "l'id e' piu' facile da riportare sulle altre tabelle collegate e yada yada" fammi aggiungere che A) e' il foxxuto computer che riporta i dati, non tu a manella, quindi il fatto che l'id sia 1 carattere o 200 non frega niente e B) l'id di questo foxxuto database e' un numero esadecimale autogenerato di 255 caratteri. Si', hai letto bene. DUECENTOCINQUANTACINQUE.
Comunque, oltre alla tabella "teams" c'e' una tabella "users". La quale ha un altro bellissimo id autogenerato di altrettanti caratteri (state vedendo un certo modus operandi nella cosa?). E poi c'e' una stupenda tabella "Teams-Users" che contiene... id_utente (ok, e su questo non c'e' niente da ridire), id_team (idem con patate) e poi... UN ALTRO, ENNESIMO, INUTILE, RIDICOLO, id autogenerato da 255 caratteri! A che pro???? Perche????
Ah, se ve lo state domandando, il netto risultato e' che una coppia utente-team puo' (e finisce per) essere inserita N-mila volte in quella foxxuta tabella.
Comunque sono qui che sto maledicendo i programmatori di sta' cosa. Quando mi arriva Bert.
Bert - Senti, ho UL al telefono. Hanno un serio problema con la loro connessione
interdet, pare che vada su e giu come uno jo-jo. E lui e' preoccupato che possano
perdere la posta.
IO - Arrrrridajie. La posta non viene persa, semmai resta in coda finche' il
server non e' disponibile.
Bert - Comunque loro vorrebbero temporaneamente girare la posta sul nostro mail
server in modo da poterla ricevere e leggere anche se il loro server e' fuori
combattimento. Si puo' fare?
IO - Si puo' fare si. Ma se il problema e' che la loro connessione INTERNET
e' fuori combattimento come fanno a leggere la posta dal nostro server?
Bert - Non credo che a questo ci abbiano pensato.
IO - Comunque, se vuoi che gli dia la brutta notizia, passamelo pure.
Cosi' mi metto a parlare con questo tizio.
UL - ... e cosi' per evitare blocchi dell'attivita' avevamo pensato...
IO - Si, ma se il problema e' che la vostra connessione internet e' fuori uso,
come pensate di leggere la posta dal nostro server?
UL - Hemmm... Come sarebbe a dire?
IO - Da quello che mi hanno detto il problema e' che la vostra connessione
internet e' fuori uso, giusto?
UL - Ah. No, mi sono spiegato male. E' il server di posta che ha problemi.
IO - Ah. E sostituirlo?
UL - Si infatti, e' quello che vogliamo fare, solo che mentre noi lo sostituiamo
la posta rimbalza.
IO - La posta non rimbalza. Al massimo finisce in coda. Quindi quello che dovete
fare e' prendere il server nuovo, installarlo, prepararlo, spegnere quello
vecchio, mettere quello nuovo al suo posto e spingere il bottone. Poi con calma
e tranquillita' tirare fuori la posta dal server vecchio e passarla su quello nuovo.
Se pianificate le cose per bene ci mettete al massimo un paio d'ore.
UL - Un Paio D'Ore???? Un paio d'ore senza ricevere posta???
Inconcepibile. Per il nostro business la posta elettronica e' essenziale!
IO - (trattenendo non so come gli ululati) Suppongo percio' che il vostro
server di posta sia un cluster ha con connessione internet ridondante.
UL - He?
IO - Voglio dire... se il vostro server di posta e' un volgare server puo' sempre
guastarsi no? Se si guasta...
UL - Hemmm... in effetti non ci ho mai pensato... voi potreste installare una
roba del genere?
IO - ...forse e' meglio se parla con il nostro ufficio commerciale.
Ora, potrei sentirmi in colpa, ma d'altra parte, se non ha ancora capito che Failure Is Always An Option non e' colpa mia...
Davide
21/07/2009 07:46
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.
Ma... By Anonymous coward posted 20/07/2009 10:10
failure is always an option By Andrea Ballarati posted 20/07/2009 10:38
Per quanto riguarda le chiavi primarie sono del tuo stesso partito e se la base dati è strutturata opportunamente la necessità di ricorrere alle autogenerate è ridotta al minimo.
PS: nei feed trovo la codifica al posto di alcuni caratteri ad es. l'apostrofo '. Mi succede solo con i feed del tuo sito e volevo segnalartelo. Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.0.11) Gecko/2009060308 Ubuntu/9.04 (jaunty) Firefox/3.0.11 -- Andrea Ballarati
255^16? By Davide Inglima posted 20/07/2009 11:17
Vecchia pubblicità che girava in televisione o sulle riviste di software in UK durante i primi anni '90, e che é stata successivamente bandita (per ovvi motivi).
Comunque spesso chi progetta il DB non é chi poi deve smazzarsi a costruire il modello di dati, ad accedervi per leggerceli e scriverceli ed ovviamente subire le proposte sul come "ottimizzare il tutto" (e la cosa, dal pdv di un programmatore, é abbastanza orribile: maledette le tabelle di relazione!!!). -- http://limacat.blogspot.com
pk... By dpantaleo posted 20/07/2009 11:31
ah, già! non so perché, ma nei feed mi compare la sequenza di escape anziché l'apostrofo -- dpantaleo
"Nemo reverte ab nos..."
Chiavi Primarie Autogenerate Forever By Andrea posted 20/07/2009 11:35
come quando lavoravo da $laviamoipannisporchi: codice articolo parlante, generato in base alle caratteristiche dell'articolo, ovviamente siccome è già univoco di per sè non va bene, ci vuole una PK autogenerata; SUSL dixit: così possiamo cambiare senza paura codice articolo, e già che ci siamo estendiamo il ragionamento anche all'anagrafe clienti, e pure a tutto il resto, perchè IO SONO IO E VOI NON SIETE UN CA$$O.
Devo proprio dire cos'è successo quando qualcuno ha cambiato codici articolo e codici cliente e codici magazzino a metà periodo di fatturazione e DOPO ci si è accorti che nelle tabelle dei movimenti NON veniva riportata la PK? -- Andrea
apostrofo By Anonymous coward posted 20/07/2009 11:54
P.S.: Complimenti per il lavoro -- Anonymous coward
Murphy By Marco Colombo posted 20/07/2009 12:52
Per il resto, pare sia di moda pretendere che la posta non fallisca mai, ovviamente dopo averla piazzata su un PC di recupero... -- .TM.
@ Marco Colombo By Davide Bianchi posted 20/07/2009 13:40
> e contemporaneamente che 'Failure Is Always An Option'?
E dove starebbe il conflitto? Affermare che una cosa bisogna farla "bene" non vuole dire "infallibile".
> per le PK che DEVONO essere uniche e immodificabili.
Quella e' la definizione di PK. Se non e' unica e non e' immodificabile, non e' una PK. Altrimenti hai delle strane idee sui database.
-- Davide Bianchi
@ Davide Bianchi By Angkarn posted 20/07/2009 16:57
Regole delle quali i committenti tendono a sbattersene: i dati sono loro e gli informatici devono offrire un servizio (parole loro, ovvio).
Mi è capitato che un determinato "capo-gestione" decidesse che tutti i codici delle anagrafiche degli articoli dovessero cambiare. L'articolo "pippo" diventava "123", "pluto" si tramutava in "234" e così via. E ho dovuto farlo. Per assurdo, addirittura senza poter avere un fermo macchina. Così mentre diverse gestioni continuavano a lavorare imperterrite, io disabilitavo decine di constraints e aggiornavo altrettante tabelle con i nuovi codici...
E poi si lamentavano se quando dovevo rivalidare i constraints il sistema rallentava.
-- Angkarn
@ Angkarn By Davide Bianchi posted 20/07/2009 19:02
I committenti possono anche sbattersene ma gli informatici, analisti, dba eccetera eccetera NON POSSONO e non devono sbattersene.
> Mi è capitato che un determinato "capo-gestione" decidesse che tutti i codici delle anagrafiche degli articoli dovessero cambiare.
Si', anche a me. Infatti il progetto duro' 5 mesi per ricodificare tutto. Non e' che ti svegli alla mattina e lo fai.
-- Davide Bianchi
@ Davide Bianchi By Angkarn posted 21/07/2009 08:43
> eccetera eccetera NON POSSONO e non devono sbattersene.
No di certo, gli informatici (o meglio, io) non se ne devono sbattere. Ma è Davide contro Golia. Quando hai di fronte un mega-direttore, con stipendio annuale a 5 zeri, che impone di farlo... è un pessimo modo di spendere il nostro tempo, ma alla fine lo fai.
> Si', anche a me. Infatti il progetto duro' 5 mesi per ricodificare tutto. Non > e' che ti svegli alla mattina e lo fai.
Nel mio caso, complice anche il fatto che il db lo conosco meglio di casa mia, mi bastarono 2 giorni. Probabilmente, se fossero serviti mesi, non si sarebbe fatto.
-- Angkarn
@ Davide Bianchi By Marco Colombo posted 27/07/2009 10:29
Fai presto a dire che le PK devono avere certe caratteristiche per definizione. Quella è la teoria. "In theory, theory and practice are the same. In practice, they are not." E il tuo sistema deve essere pronto ad accettare il fallimento della teoria.
In certi casi, semplicemente rifiutare un dato perché "non corretto" potrebbe non essere accettabile, specie se stai migrando da un sistema precedente. A volte hai il lusso di prima fixare i problemi, poi migrare. A volte no, devi prima prendere in pancia tutto, e poi lavorare sui conflitti. E ti scordi di usare PK naturali, in quel caso. Basta un semplice errore di trascrizione (sto pensando ad un archivio cartaceo) ed ecco che una persona diventano due oppure due diventano una, con buona pace delle PK naturali (comunque tu le scelga, l'errore è a monte, nei dati).
Avere un DB in cui si usini PK naturali è una specie di meta finale. Quando va bene (per i DB che fai TU per TE), è così dall'inizio. A volte, è la conclusione del lavoro, in altri casi, semplicemente un'utopia. Failure is always an option. -- .TM.
nessuna novità sotto il sole ... By Gabriele Corrieri posted 20/07/2009 13:08
sarà, ma dopo tutto quello che è successo, effettivamente è meglio che tu stia cambiando il negriero ... sperando che il futuro sia meglio del precedente, anche se, vedendo un po' in giro e anche le tue storie, sono tutti uguali, sembra che abbiano il cervello prestampato a mo' di formina (sì, quella per la sabbia, che usano i bimbi al mare!) prestampato e tutto uguale!! -- Gabriele
Chiavi autogenerate e CRM By Daniele posted 20/07/2009 13:11
Finche' qualcuno non ha espresso l'esigenza improcrastinabile di cambiare la definizione al gruppo... normalmente da singolare a plurale, perche' stava meglio... Questo dopo due anni di esistenza del gruppo e di storicizzazione di parti del db...
Ergo: parte integrante dell'analisi e' pensare a chi finira' in mano l'applicazione...
Magari i 256 caratteri esadecimali pero' poteva risparmiarseli!
P.S.: sono entrato anch'io nel club di quelli stesi in moto mentre tornavano dal lavoro! C'e' qualche premio? -- Daniele
@ Daniele By Anonymous coward posted 21/07/2009 15:27
vale anche per chi si sdraia con la bici?
WM -- Anonymous coward
no bhe By Anonymous coward posted 20/07/2009 14:34
@ Anonymous coward By Davide Bianchi posted 20/07/2009 15:21
E' a quello che servono le specifice "nome team non si cambia". Punto.
> non usarle in genere e' sintomo di cattiva programmazione
Le palle.
> porta ridondanza dei dati e spreco di query
Le palle (2).
-- Davide Bianchi
@ Davide Bianchi By Anonymous coward posted 20/07/2009 16:03
Le palle.
92 minuti di applausi -- Anonymous coward
@ Davide Bianchi By Anonymous coward posted 20/07/2009 16:16
E' a quello che servono le specifice "nome team non si cambia". Punto.
Mi dispiace dirtelo Davide ma a mio avviso questo approccio è decisamente sbagliato, sia perchè dovresti avere tutta l'esperienza necessaria per sapere che le specifiche cambiano dato che alla fine decide chi paga anche se spesso in maniera poco ragionevole, sia perchè questo approccio non prevede la possibilità che l'utente semplicemente sbagli la chiave e se ne accorga in un secondo momento. Che succede se registro un cliente con il codice XXX (PK) e mi accorgo dopo un mese che invece era XXY mentre quel dato è già finito dentro decine di fatture e documenti vari collegati ? Ciao a tutti
--
Davide Bianchi -- Anonymous coward
@ Anonymous coward By Davide Bianchi posted 20/07/2009 16:35
No, questo e' l'approccio giusto , l'approccio sbagliato e' "scriviamo le cose in modo che NON funzionino fin dall'inizio, tanto poi le dobbiamo cambiare. Iniziare con delle specifiche solide e' il primo passo. Fare una revisione dopo 6 mesi perche' ti sei reso conto che all'inizio avevi capito male il problema e' normale. E' quello che solitamente si chiama "ciclo di sviluppo".
> alla fine decide chi paga anche se spesso in maniera poco ragionevole
E' a questo che servono i capi progetto: a mettere in chiaro le responsabilita' di chi fa' le richieste e chi le implementa.
> Che succede se registro un cliente con il codice XXX (PK) e mi accorgo dopo un mese che invece era XXY
Che sei un coglione, che dovevi pensarci prima e che pagherai chi di dovere un pacco di soldi per risistemare il tuo errore. Perche' pensi che quelli di SAP prendano tanti soldi?
-- Davide Bianchi
@ Anonymous coward By Andrea Ballarati posted 20/07/2009 17:48
Scusa eh ma se invece lo stesso cliente viene inserito tre volte magari con dati errati e discordanti non c'è problema? E se fai le verifiche di congruità al momento dell'immissione non è la stessa cosa che ti consente di mantenere la chiave naturale?
L'integrità referenziale c'è modo di mantenerla, volendo. -- Andrea Ballarati
@ Davide Bianchi By Angkarn posted 20/07/2009 16:47
Non è che quest'integralismo ci stia.
Di esperienza di grossi database ne ho a sufficienza per sapere che i casi in cui l'ID autogenerato serve eccome: dalle tabelle in cui non sarebbe possibile trovare un'altra PK (esempi: una tabella di log in cui ogni segnalazione può essere divisa in più righe; una tabella di log i quali debbono essere identificati univocamente per essere segnalati su una tabella figlia; una tabella di relazione in cui i campi "identificativi" possono anche essere nulli) a quelle nelle quali la chiave primaria naturale sarebbe così lunga da essere esageratamente pesante riportarla integralmente sulle tabelle figlie (qualcosa tipo 200-300 byte al posto di 9), passando per molti altri casi.
Sono d'accordo sul fatto che le chiavi autogenerate non debbano essere dei mostri tipo quelle da te citate: pur lavorando su tabelle che arrivano a centinaia di milioni di record, la mia PK autogenerata più lunga è di 12 byte.
-- Angkarn
@ Angkarn By Davide Bianchi posted 20/07/2009 19:00
Dissento.
> Di esperienza di grossi database ne ho a sufficienza per sapere che i casi in cui l'ID autogenerato serve eccome:
Se vai e ti leggi quel mio commento/documento scoprirai che io penso che ci sono dei casi in cui non hai altra possibilita', ma nel 99% degli altri casi la possibilita' c'e' eccome.
> alle tabelle in cui non sarebbe possibile trovare un'altra PK (esempi: una tabella di log in cui ogni segnalazione può essere divisa in più righe
?? Che cappero di tabella di log hai che le segnalazioni sono su piu' righe??
Questa a casa mia si chiama errore di progettazione.
> essere segnalati su una tabella figlia; una tabella di relazione in cui i campi "identificativi" possono anche essere nulli
Un campo identificativo che puo' essere nullo non e' un campo identificativo.
-- Davide Bianchi
@ Davide Bianchi By Kent Morwath posted 20/07/2009 20:31
Le specifiche funzionali non spettano al programmatore e non possono essere una scusa per essere pigri. Il programma deve adattarsi alle esigenze degli utenti, non viceversa. Cose come "nome del team" o simili non sono immutabili di per sé, può e deve essere possibile cambiarle se necessario, impedire di farlo solo perché così fa comodo al DBA/programmatore non è da professionista, mi dispiace.
Anche perché poi la richiesta ti arriva e poi gestrila diventa ancora più complesso. Poi ci sono buone chiavi surrogate e cattive chiavi, così come ci sono buone chiavi naturali e cattive chiavi naturali.
-- Kent Morwath
@ Kent Morwath By Davide Bianchi posted 20/07/2009 20:57
No, spettano all'analista ed al capo progetto, di concerto con chi il software deve usarlo.
-- Davide Bianchi
mai es chiu el By Matteo Jurman posted 20/07/2009 15:01
quando lavoravo come 'bugbuster' presso $noivendiamosistemidisorveglianza (no, non avevo la magliettina con uno scarrafone dentro il cartello di divieto, NOSSIGNORI) un giorno $bancaamericanaimportantissima ci ha mandato da controllare perche' e percome un suo sistema non rispondesse alle chiamate del 'sistema master'... gira rigira e ravana nel codice, niente di strano... gira rigira ravana nel db, sembra tutto a posto, tranne un piiiccolissimo spazio messo in una stringa di testo, che giustamente nel codice (chissa' chi lo ha scritto, forse il sottoscritto o forse l'altro baboon coder - ciao ing. C! - che aveva realizzato il sw) veniva eliminato IN LETTURA dal db ma che IN SCRITTURA veniva salvato nel db...
risolto cosi' brillantemente il problema, segnalo la cosa a chi di dovere, e conoscendo l'ambiente di lavoro NON mi aspetto alcun ringraziamento... arrivano, nell'ordine, chiamate dal responsabile IT di $bancaamericanaimportantissima, del nostro commerciale mmmericano e del responsabile vendite intl, tutti entusiaste... beh, sono soddisfazioni no?
ok ok lo so non e' per nulla legata con la storia e mi sa che l'avevo pure gia' raccontata, ma sono contento di rileggere, dopo tre settimane, le storie del grande D.
ah, @Daniele:
benvenuto nel club, la risposta e' NO... ma c'e' di peggio, chi viene steso ANDANDO al lavoro perche' una cretina tagliandogli la strada, gli cecchina la coppa e per finire l'opera lo guarda come dire "eh, ma e' caduto da solo, io che c'entro???" --
---
BabboMatteo
@ Matteo Jurman By Angkarn posted 20/07/2009 16:35
E' successo pure a un mio collega o.o
-- Angkarn
@ Matteo Jurman By Daniele posted 20/07/2009 22:04
benvenuto nel club, la risposta e' NO... ma c'e' di peggio, chi viene steso ANDANDO al lavoro perche' una cretina tagliandogli la strada, gli cecchina la coppa e per finire l'opera lo guarda come dire "eh, ma e' caduto da solo, io che c'entro???"
---
BabboMatteo
Beh... a me hanno fatto inversione ad U davanti.
Non POTEVA dire e' caduto da solo!!! Magra consolazione... -- Daniele
DB By Anonymous coward posted 21/07/2009 00:21
Ciao
RdT -- Anonymous coward
Bentornato up :D By Anonymous coward posted 21/07/2009 07:33
b) nel feed vedo che l'apostrofo nei nodi title viene codificato come "& # x 2 6 ; # 3 9" (senza spazi)... in pratica manca un punto e virgola dopo il 39 btw, su netvibes, caricato con chrome, si vede benone
--
Anonymous coward
acc By Simone posted 21/07/2009 11:37
"come mai non mi arriva una email?"
"come mai non riesco a spedire una mail da 8393894343 tera?"
.... no forse non è poi così bello -- - Simone
SysadminDay! By dpantaleo posted 21/07/2009 14:21
http://www.thinkgeek.com/interests/sysadmin/
http://www.thinkgeek.com/brain/contests/sysadmin.cgi -- dpantaleo
"Nemo reverte ab nos..."
@ dpantaleo By Gabriele Corrieri posted 21/07/2009 20:14
I want it all anche chi non ama i Queen ma la tecnologia mi troverà d'accordo
--
Gabriele
@Daniele e Angkarn By Matteo Jurman posted 22/07/2009 11:57
ma che il pirla sono io che al lavoro ci sono andato, con Zetina sgocciolante d'olio (meno male che il nostro supermeccanico me l'ha sistemata al volo) e ginocchio ammaccatissimo (per tacere del sedere)... --
---
BabboMatteo
Cambiare mestiere... By Anonymous coward posted 22/07/2009 22:00
@ Anonymous coward By Davide Bianchi posted 23/07/2009 07:25
C'e' posto per un barista notturno?
-- Davide Bianchi
@ Davide Bianchi By Nik posted 23/07/2009 22:39
così nelle notti insonni veniamo da te a prendere un bicchier e sentire le storie dalla tua viva voce -- ...
@ Nik By Gabriele Corrieri posted 25/07/2009 16:58
Hmm sarebbe carina questa idea ... un 'menestrello per sysadmin' .... -- Gabriele
@ Gabriele Corrieri By Davide Bianchi posted 26/07/2009 10:09
Bravely bold Sir Robin
Brought forth from Camelot.
He was not afraid to die,
Oh, brave Sir Robin!
He was not at all afraid to be killed in nasty ways.
Brave, brave, brave Sir Robin.
He was not in the least bit scared to be mashed into a pulp.
Or to have his cables gouged out, and his MX records broken!
To have his domains split, and his /dev burned away
And his file systems all hacked and mangled, brave Sir Robin.
His newsrc smashed in and his heart cut out,
And his relays removed and his routers unplugged,
And his hubs baked and his soul burnt off,
And his peni--"
(Monthy Pyton and the Quest for the Holy Grail)
-- Davide Bianchi
@ Davide Bianchi By Gabriele Corrieri posted 26/07/2009 11:25
Ecco ... giustappunto qualcosa per tenerci su
-- Gabriele
@ Davide Bianchi By Verzasoft posted 24/07/2009 12:11
Ocio che non è uno strip-club eh
--
Verzasoft
@ Anonymous coward By Daniele posted 23/07/2009 20:46
Disponibile ai festivi!!! -- Daniele
@ Anonymous coward By dpantaleo posted 24/07/2009 18:50
"Nemo reverte ab nos..."
indici non primari By leonardo posted 01/09/2009 21:39
In genere questo tipo di approccio ha risvolti positivi sia nelle prestazioni (temporali e spaziali) sia nella gestione del ciclo di vita del sistema.
Poi ci sono sempre i casi limite o degeneri che avete descritto, ma non li considererei più che casi limite. -- leonardo
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.