Tales from the Machine Room


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

Un Paio d'Ore??

Sono sempre qui che mi trastrullo (per alcuni valori di "trastrullo") con il famoso CRM di DaBoss di cui ho gia' detto. Ieri DaBoss ha deciso di tentare la strada della Importazione Dati dalla versione vecchia alla versione nuova. Versione nuova che avrebbe dovuto correggere diversi bacherozzi che, a detta di DB, impedivano il normale flusso operativo.

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

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.

44 messages this document does not accept new posts
Anonymous cowardMa... By Anonymous coward - posted 20/07/2009 10:10
Dai, dillo che ti andava di installare un bel cluster e fargli spendere un bel po' di soldi!

--
Anonymous coward


Andrea Ballaratifailure is always an option By Andrea Ballarati - posted 20/07/2009 10:38

Sacrosanta verità, di solito quando mi viene richiesto un sistema "assolutamente sicuro", dopo aver spiegato che non esiste, metto giù la lista della spesa. Dopo averla letta si trova sempre un buon compromesso.
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


Davide Inglima255^16? By Davide Inglima - posted 20/07/2009 11:17

"Il software Sierra On-Line continuerà a funzionare anche dopo la morte del proprio utente".

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


dpantaleopk... By dpantaleo - posted 20/07/2009 11:31

mmm... a me questo sembra il lavoro di $db_di_redmond, o almeno di un suo simile.
ah, già! non so perché, ma nei feed mi compare la sequenza di escape anziché l'apostrofo

--
dpantaleo
"Nemo reverte ab nos..."


AndreaChiavi Primarie Autogenerate Forever By Andrea - posted 20/07/2009 11:35

Eh si,

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


Anonymous cowardapostrofo By Anonymous coward - posted 20/07/2009 11:54

Solo come segnalazione, usando google reader come aggregatore di Feed, il titolo dell'articolo (che contiene un apostrofo) viene codificato come '.
P.S.: Complimenti per il lavoro

--
Anonymous coward


Marco ColomboMurphy By Marco Colombo - posted 20/07/2009 12:52

Avverto un curioso conflitto. Come si fa a sostenere l'uso delle PK naturali e contemporaneamente che 'Failure Is Always An Option'? Ogni volta che si afferma che un certa cosa in teoria DEVE essere in un certo modo, e che è IMPOSSIBILE che sia altrimenti, la pratica dimostra il contrario. Vale per i server in HA che è IMPOSSIBILE falliscano contemporaneamente, per i RAID che NON POSSONO perdere 3 dischi nello stesso istante, per le PK che DEVONO essere uniche e immodificabili. E, no, spesso dire "eh, ma non mi avevate detto che..." non si può.

Per il resto, pare sia di moda pretendere che la posta non fallisca mai, ovviamente dopo averla piazzata su un PC di recupero...

--
.TM.


Davide Bianchi@ Marco Colombo By Davide Bianchi - posted 20/07/2009 13:40

> Avverto un curioso conflitto. Come si fa a sostenere l'uso delle PK naturali
> 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


Angkarn@ Davide Bianchi By Angkarn - posted 20/07/2009 16:57

>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.

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


Davide Bianchi@ Angkarn By Davide Bianchi - posted 20/07/2009 19:02

> Regole delle quali i committenti tendono a sbattersene: i dati sono loro e gli informatici devono offrire un servizio (parole loro, ovvio).

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


Angkarn@ Davide Bianchi By Angkarn - posted 21/07/2009 08:43

> I committenti possono anche sbattersene ma gli informatici, analisti, dba
> 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


Marco Colombo@ Davide Bianchi By Marco Colombo - posted 27/07/2009 10:29

Non ho risposto prima perché la cosa stava degenerando in un flame. A me non interessa la questione PK naturali/generate di per sé, ma la combinazione con 'failure is always an option'.

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.


Gabriele Corrierinessuna novità sotto il sole ... By Gabriele Corrieri - posted 20/07/2009 13:08

Ciao D,
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


DanieleChiavi autogenerate e CRM By Daniele - posted 20/07/2009 13:11

Anch'io la pensavo come te!
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


Anonymous coward@ Daniele By Anonymous coward - posted 21/07/2009 15:27

> P.S.: sono entrato anch'io nel club di quelli stesi in moto mentre tornavano dal lavoro! C'e' qualche premio?

vale anche per chi si sdraia con la bici? :-\)

WM

--
Anonymous coward


Anonymous cowardno bhe By Anonymous coward - posted 20/07/2009 14:34

no bhe, occhio a non sottovalutare le autogenerate. Il nome dici e' univoco? ottimo, ma sappi che in futuro $idiota vorra' cambiare il nome del team. E' palese, murphy non perdona. E se questa viene utilizzata in una tabellaB, per cambiare un parametro (nome_team) dovrai fare due query anziche' 1 (update nome_team in tabella A e in tabella B per non perdere il riferimento, contro un update solo di nome_team). Sono molto rari i casi in cui puoi permetterti di non usare le autogenerate, non usarle in genere e' sintomo di cattiva programmazione, porta ridondanza dei dati e spreco di query. La normalizzazione delle tabelle e' molto importante, e non farla e' sinonimo di cattiva programmazione e poca conoscenza della teoria delle basi di dati!

--
Anonymous coward


Davide Bianchi@ Anonymous coward By Davide Bianchi - posted 20/07/2009 15:21

> no bhe, occhio a non sottovalutare le autogenerate. Il nome dici e' univoco? ottimo, ma sappi che in futuro $idiota vorra' cambiare il nome del team.

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


Anonymous coward@ Davide Bianchi By Anonymous coward - posted 20/07/2009 16:03

> non usarle in genere e' sintomo di cattiva programmazione

Le palle.


92 minuti di applausi

--
Anonymous coward


Anonymous coward@ Davide Bianchi By Anonymous coward - posted 20/07/2009 16:16

> > no bhe, occhio a non sottovalutare le autogenerate. Il nome dici e' univoco? ottimo, ma sappi che in futuro $idiota vorra' cambiare il nome del team.

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


Davide Bianchi@ Anonymous coward By Davide Bianchi - posted 20/07/2009 16:35

> Mi dispiace dirtelo Davide ma a mio avviso questo approccio è decisamente sbagliato,

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


Andrea Ballarati@ Anonymous coward By Andrea Ballarati - posted 20/07/2009 17:48

> 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

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


Angkarn@ Davide Bianchi By Angkarn - posted 20/07/2009 16:47

> Le palle (2).

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


Davide Bianchi@ Angkarn By Davide Bianchi - posted 20/07/2009 19:00

> Non è che quest'integralismo ci stia.

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


Kent Morwath@ Davide Bianchi By Kent Morwath - posted 20/07/2009 20:31

> E' a quello che servono le specifice "nome team non si cambia". Punto.

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


Davide Bianchi@ Kent Morwath By Davide Bianchi - posted 20/07/2009 20:57

> Le specifiche funzionali non spettano al programmatore

No, spettano all'analista ed al capo progetto, di concerto con chi il software deve usarlo.

--
Davide Bianchi


Matteo Jurmanmai es chiu el By Matteo Jurman - posted 20/07/2009 15:01

... mi e' venuta in mente una facezia:
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


Angkarn@ Matteo Jurman By Angkarn - posted 20/07/2009 16:35

>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???"

E' successo pure a un mio collega o.o

--
Angkarn


Daniele@ Matteo Jurman By Daniele - posted 20/07/2009 22:04

> 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

Beh... a me hanno fatto inversione ad U davanti.
Non POTEVA dire e' caduto da solo!!! Magra consolazione...

--
Daniele


Anonymous cowardDB By Anonymous coward - posted 21/07/2009 00:21

Saluti a Davide, grazie per le storie. E testimonio pure io che se ho una minima possibilità di Primary Key "decente", niente ID e niente autogeneranti :-\)

Ciao
RdT

--
Anonymous coward


Anonymous cowardBentornato up :D By Anonymous coward - posted 21/07/2009 07:33

a) Bentornato online e sempre grazie per le tue storie :D
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 :P btw, su netvibes, caricato con chrome, si vede benone ;\)

--
Anonymous coward


Simoneacc By Simone - posted 21/07/2009 11:37

vedendo le vostre discussioni mi fate venire a piacere la mia gestione del server di posta!

"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


dpantaleoSysadminDay! By dpantaleo - posted 21/07/2009 14:21

Lo so, è presto, però... :P
http://www.thinkgeek.com/interests/sysadmin/
http://www.thinkgeek.com/brain/contests/sysadmin.cgi

--
dpantaleo
"Nemo reverte ab nos..."


Gabriele Corrieri@ dpantaleo By Gabriele Corrieri - posted 21/07/2009 20:14

>http://www.thinkgeek.com/interests/sysadmin/

I want it all :D anche chi non ama i Queen ma la tecnologia mi troverà d'accordo ;\)

--
Gabriele


Matteo Jurman@Daniele e Angkarn By Matteo Jurman - posted 22/07/2009 11:57

si, ma io non dicevo che avrei ammazzato la signora (tra l'altro le due testimoni erano a MIO favore)...
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


Anonymous cowardCambiare mestiere... By Anonymous coward - posted 22/07/2009 22:00

Io mi sono stufato.... sono passato da sistemista senior a gestore di un bar diurno....

--
Anonymous coward


Davide Bianchi@ Anonymous coward By Davide Bianchi - posted 23/07/2009 07:25

> Io mi sono stufato.... sono passato da sistemista senior a gestore di un bar diurno....

C'e' posto per un barista notturno?

--
Davide Bianchi


Nik@ Davide Bianchi By Nik - posted 23/07/2009 22:39

> C'e' posto per un barista notturno?

così nelle notti insonni veniamo da te a prendere un bicchier e sentire le storie dalla tua viva voce

--
...


Gabriele Corrieri@ Nik By Gabriele Corrieri - posted 25/07/2009 16:58

>>così nelle notti insonni veniamo da te a prendere un bicchier e sentire le storie dalla tua viva voce

Hmm sarebbe carina questa idea ... un 'menestrello per sysadmin' ....

--
Gabriele


Davide Bianchi@ Gabriele Corrieri By Davide Bianchi - posted 26/07/2009 10:09

> Hmm sarebbe carina questa idea ... un 'menestrello per sysadmin' ....

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


Gabriele Corrieri@ Davide Bianchi By Gabriele Corrieri - posted 26/07/2009 11:25

> > Bravely bold Sir Robin ...

Ecco ... giustappunto qualcosa per tenerci su ;\)

--
Gabriele


Verzasoft@ Davide Bianchi By Verzasoft - posted 24/07/2009 12:11

> C'e' posto per un barista notturno?

Ocio che non è uno strip-club eh :\)

--
Verzasoft


Daniele@ Anonymous coward By Daniele - posted 23/07/2009 20:46

> Io mi sono stufato.... sono passato da sistemista senior a gestore di un bar diurno....

Disponibile ai festivi!!!

--
Daniele


dpantaleo@ Anonymous coward By dpantaleo - posted 24/07/2009 18:50

24/7!!!

--
dpantaleo
"Nemo reverte ab nos..."


leonardoindici non primari By leonardo - posted 01/09/2009 21:39

Secondo me l'approccio più generale e più corretto è: mantenere le chiavi primarie numeriche e corte, mettere indici univoci laddove servano.
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


44 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