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.
44 messaggi this document does not accept new posts
Ma... Di Anonymous coward postato il 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
failure is always an option Di Andrea Ballarati postato il 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
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? Di Davide Inglima postato il 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
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... Di dpantaleo postato il 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..."
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 Di Andrea postato il 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
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 Di Anonymous coward postato il 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
P.S.: Complimenti per il lavoro -- Anonymous coward
Murphy Di Marco Colombo postato il 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.
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 Di Davide Bianchi postato il 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
> 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 Di Angkarn postato il 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
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 Di Davide Bianchi postato il 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
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 Di Angkarn postato il 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
> 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 Di Marco Colombo postato il 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.
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 ... Di Gabriele Corrieri postato il 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
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 Di Daniele postato il 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
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 Di Anonymous coward postato il 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
vale anche per chi si sdraia con la bici?
WM -- Anonymous coward
no bhe Di Anonymous coward postato il 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
@ Anonymous coward Di Davide Bianchi postato il 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
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 Di Anonymous coward postato il 20/07/2009 16:03
> non usarle in genere e' sintomo di cattiva programmazione
Le palle.
92 minuti di applausi -- Anonymous coward
Le palle.
92 minuti di applausi -- Anonymous coward
@ Davide Bianchi Di Anonymous coward postato il 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
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 Di Davide Bianchi postato il 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
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 Di Andrea Ballarati postato il 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
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 Di Angkarn postato il 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
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 Di Davide Bianchi postato il 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
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 Di Kent Morwath postato il 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
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 Di Davide Bianchi postato il 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
No, spettano all'analista ed al capo progetto, di concerto con chi il software deve usarlo.
-- Davide Bianchi
mai es chiu el Di Matteo Jurman postato il 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
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 Di Angkarn postato il 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
E' successo pure a un mio collega o.o
-- Angkarn
@ Matteo Jurman Di Daniele postato il 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
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 Di Anonymous coward postato il 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
Ciao
RdT -- Anonymous coward
Bentornato up :D Di Anonymous coward postato il 21/07/2009 07:33
a) Bentornato online e sempre grazie per le tue storie 
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
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 Di Simone postato il 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
"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! Di dpantaleo postato il 21/07/2009 14:21
Lo so, è presto, però...
http://www.thinkgeek.com/interests/sysadmin/
http://www.thinkgeek.com/brain/contests/sysadmin.cgi -- dpantaleo
"Nemo reverte ab nos..."
http://www.thinkgeek.com/interests/sysadmin/
http://www.thinkgeek.com/brain/contests/sysadmin.cgi -- dpantaleo
"Nemo reverte ab nos..."
@ dpantaleo Di Gabriele Corrieri postato il 21/07/2009 20:14
>http://www.thinkgeek.com/interests/sysadmin/
I want it all anche chi non ama i Queen ma la tecnologia mi troverà d'accordo
--
Gabriele
I want it all
anche chi non ama i Queen ma la tecnologia mi troverà d'accordo
--
Gabriele
@Daniele e Angkarn Di Matteo Jurman postato il 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
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... Di Anonymous coward postato il 22/07/2009 22:00
Io mi sono stufato.... sono passato da sistemista senior a gestore di un bar diurno....
--
Anonymous coward
@ Anonymous coward Di Davide Bianchi postato il 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
C'e' posto per un barista notturno?
-- Davide Bianchi
@ Davide Bianchi Di Nik postato il 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 -- ...
così nelle notti insonni veniamo da te a prendere un bicchier e sentire le storie dalla tua viva voce -- ...
@ Nik Di Gabriele Corrieri postato il 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
Hmm sarebbe carina questa idea ... un 'menestrello per sysadmin' .... -- Gabriele
@ Gabriele Corrieri Di Davide Bianchi postato il 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
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 Di Gabriele Corrieri postato il 26/07/2009 11:25
> > Bravely bold Sir Robin ...
Ecco ... giustappunto qualcosa per tenerci su
-- Gabriele
Ecco ... giustappunto qualcosa per tenerci su
-- Gabriele
@ Davide Bianchi Di Verzasoft postato il 24/07/2009 12:11
> C'e' posto per un barista notturno?
Ocio che non è uno strip-club eh
--
Verzasoft
Ocio che non è uno strip-club eh
--
Verzasoft
@ Anonymous coward Di Daniele postato il 23/07/2009 20:46
> Io mi sono stufato.... sono passato da sistemista senior a gestore di un bar diurno....
Disponibile ai festivi!!! -- Daniele
Disponibile ai festivi!!! -- Daniele
@ Anonymous coward Di dpantaleo postato il 24/07/2009 18:50
24/7!!!
--
dpantaleo
"Nemo reverte ab nos..."
"Nemo reverte ab nos..."
indici non primari Di leonardo postato il 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
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
