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.
24 messaggi this document does not accept new posts
Di Anonymous coward postato il 19/12/2011 08:46
L'importante e' avere SEMPRE TUTTO scritto via mail, con i vari "ma siete sicuri?" ed i relativi "si, siamo sicuri, fate come diciamo noi perche' noi siamo quelli che pagano, in modo tale da pararsi il sedere quando vengono con "ma qui non funziona un caiser" potendo cosi rispondere "noi ve lo avevamo detto, voi avete insistito".
Non so voi, ma io mi sono stufato di lavorare nel reparto "sistemiamo per un pugno di lenticchie i casini stellari che avete creato con la vostra incompentenza/iniettitudine/sordita'_agli_avvertimenti/mancanza_di_pianificazione/etcetc"
-- Anonymous coward
Di Luca Bertoncello postato il 19/12/2011 08:49
Che dire invece di quelli che "inseriscono tutto nel DB senza controlli, che tanto quelli li faccio con PHP"?
Quanti ne conosco, di quelli... E quante volte mi capita di vedere records n-plicati nel DB... -- Luca Bertoncello
Di Zomas postato il 19/12/2011 09:06
Più o meno come mi accadde in una precedente azienda: solo che, a differenza tua, me ne usci con un "come ti avevo detto di procedere io..."
...
Ti ho detto che ho cambiato lavoro?...
Di Anonymous Comrade postato il 19/12/2011 09:06
Let it roll, baby, roll
Let it roll, baby, roll
Let it roll, baby, roll
Let it roll, all night long
[The BackDoors: Datawarehouse Blues]
-- Anonymous Comrade
Di Carlo postato il 19/12/2011 09:17
Pensa positivo: magari ha imparato la lezione e la prossima volta non lo fa piu'..........
Carlo
Di ringo postato il 19/12/2011 09:33
Vogliamo parlare del comando PREPARE da inserire prima di una query parametrica che deve essere ripetuta decinaia di migliaia di volte?
Cos'è? Mi dice il programmatroto?
Lasciamo perdere, rispondo io.
L'ho detto che la query °parametrica° era una cosa del tipo
q="UPDATE CAMPO SET VALORE=" + valore + " WHERE ID=" + id
sql.execute q;
o era sottinteso?
-- ringo
Di leonick postato il 19/12/2011 10:14
Ma è straordinario: un programmatroto TI HA CAPITO, decidendo di seguire il tuo consiglio! 
Mi aspettavo che si lamentasse che il db server è lento... bisogna festeggiare: forse l'umanità ha ancora qualche speranza di sopravvivenza, dopotutto! 
Di Anonymous coward postato il 19/12/2011 11:20
> L'ho detto che era venerdi' pomeriggio alle 16.30?
> Dopo un paio d'ore,
>79 ore dopo, lunedi', mi arriva la telefonata del 'responsabile it' (CL) della situazione.
La Terra ha giorni di circa 24 ore. Ora, 3 giorni sono 72 ore, per cui se lo script e' partito alle 16.30 di venerdi e' la telefonata arriva 79 ore dopo, ci troviamo alle 16.30+(79-72) = 23.30 di lunedi' sera, se poi contiamo pure il Dopo un paio d'ore arriviamo alle 1.30 del martedi.
Se i numeri ed i conti sono giusti, allora capisco perche' al lavoro sei sull'incazzato stabile.
-- Anonymous coward
Di Lucazeo postato il 19/12/2011 11:22
Il problema del progammatore è fondamentalmente il seguente: non potrebbe fare una truncate su una tabella che viene referenziata da una chiave esterna (questo è vero per SQL server, non so se era il caso).
In questi casi si fa comunque una truncate, facendo prima un DROP dei vincoli e ricreandoli dopo, ma questo significa mettersi lì a fare le cose con cognizione
Sono commosso che abbia utilizzato delle chiavi esterne (se è vero che lo ha fatto), spesso il db viene utilizzato.. quasi come un file di testo.
-- Lucazeo
Di lufo88 postato il 19/12/2011 11:47
Dopo aver fatto uno stage presso $azienda_italiana dove ho sviluppato un'interfaccia per ricavare i risultati degli explain su tre DB diversi, ho capito anch'io che i DB sono maltrattati. Per capirsi la prima query che ho testato era una frase SQL lunga circa 40 righe, con almeno 4 subquery, senza contare i LEFT OUTER JOIN utilizzati come se non esistesse altro. Il piano di esecuzione era composto da circa 70 operazioni di cui la maggior parte erano scan su tabelle di circa 30.000 record senza alcuna indice! Inutile dire che il DB di produzione conteneva minimo un milione di record per tabella. Poi si lamentano che il server e' lento!
-- lufo88
Di Anonymous coward postato il 19/12/2011 12:54
Beh, se hanno fatto le cose 'più o meno' come andavano fatte, i record cancellati andavano COMUNQUE cancellati, quindi puoi killare lo script senza problemi e passare il nuovo script 'giusto', no?
O, come è probabile parlando di programmatroti, gli altri script lavoravano sulle stesse tabelle e sugli altri valori? =p
-- Anonymous coward
Di Anonymous coward postato il 19/12/2011 12:56
"Il programmatroto in oggetto ha blaterato di 'coerenza dei dati' ed altre cose varie," sì, perché probabilmente per eseguire la truncate deve disabilitare un po' di constraint e poi riabilitarli, senza contare il dover creare le tabelle temporanee e poi eliminarle... e questo richiede più lavoro. Tanto lui l'ha provato sulla sua tabella di test con 6 record e lì funziona benissimo.
Ed in genere in situazioni di questo tipo la lotta fra la pigrizia del programmatore e quella del sistemista o DBA (si incontra anche questa "ah, ma questo aggiornamento richiede la patch xyz? Non l'abbiamo installata" "Ma era la Critiical Patch Update di gennaio!" "eh sì, ma noi non le installiamo, la rana, la fava, ecc. ecc.")
-- Anonymous coward
Di Il codardo senza nome postato il 19/12/2011 13:10
Certo è come quando il vicino di casa prende un martello demolitore elettrico formato godzilla e si mette a staccare piastrelle del pavimento. Martella per 3 gg di fila dalle ore 8.00 alle ore 19.00 e ad un certo punto incontra casualemente un tubo dell'acqua condominale.. non esiste un roll-back in quel caso vero ? .. sgrunt 
Di Anonymous coward postato il 19/12/2011 13:28
Proceduralmente fantastico!
-- Anonymous coward
Di Anonymous Swiss Coward postato il 19/12/2011 14:14
Il problema è che i programmatori ormai vedono i database come una commodity qualunque. Se uno si mette oggi a sbirciare le query che girano in server di produzione c'è da spaventarsi, spesso si trovano stored procedure e query varie che nemmeno usano le variabili bind. :/
Tanto ci pensano i core e le san con fibra...
-- Anonymous Swiss Coward
Di Macpi100 postato il 19/12/2011 15:32
Beh, se vuoi i miei 2 cent, una volta mi è stato chiesto se non fosse possibile utilizzare una TRUNCATE [..] WHERE..
lascio a te ogni commento..
-- Macpi100
Di Guido postato il 19/12/2011 21:37
Davide, grazie che ci sei te che ci fai sorridere perchè è periodaccio per chi cerca lavoro...
salut 
Di Anonymous coward postato il 20/12/2011 12:50
L'unica spiegazione per usare il delete, potrebbe essere che si voglia essere sicuri che non venga violata qualche constraint. Pero' se ci sono dei constraint, a maggior ragione la delete sara' piu' lenta, visto che per ogni record dovra' controllare che non ci siano constraint coinvolti, in pratica una select ulteriore per ogni contraint coinvolto.
Ma almeno mi aspetto che mettano un bel commit ogni tot record. Giusto per non intasare il db con un unica transazione da 18 milioni di record.
-- Anonymous coward
@ Anonymous coward Di Anonymous coward postato il 22/12/2011 22:16
"L'unica spiegazione per usare il delete, potrebbe essere che si voglia essere sicuri che non venga violata qualche constraint. Pero' se ci sono dei constraint, "
Se crei una tabella temporanea con gli stessi constraint, copi lì i record da non eliminare, svuoti la tabella originale in un colpo solo e poi ricopi i dati (o droppi la tabella e rinomini la temporanea) sei comunque sicuro che non venga violato alcun constraint. In più lo spazio occupato dalla tabella non sembra una forma di gruviera con i record superstiti sparpagliati per tutto lo spazio occupato prima, cosa che può richiedere una riorganizzazione della tabella o le prestazioni possono anche andare a ramengo in caso ti table scan.
"Ma almeno mi aspetto che mettano un bel commit ogni tot record. "
Okkio che se lo fai troppo spesso la lentezza potrebbe pure aumentare, un commit è un commit e richiede un'ulteriore serie di operazioni.
-- Anonymous coward
Di Massimiliano postato il 20/12/2011 18:29
Queste storie mi fanno sempre piegare in due dalle risate.
Grande, auguri di buon Natale Big D.
-- Massimiliano
Di Alberto postato il 21/12/2011 01:39
e che chissà che progettone se zappano via il 90% dei dati...
Tienili stretti questi personaggi perché ci rendono la vita allegra.
-- zioniccio
@ Alberto Di Anonymous coward postato il 21/12/2011 21:13
>e che chissà che progettone se zappano via il 90% dei dati...
Non sono tanti...se consideri che i dati inutili o errati ( con un programmatroto cosi' ) saranno il 100% .
Il bello verra' quando ( dopo il commit ) si accorgeranno che il database non va piu' e vi chiederanno di ripristinarlo tutto da zero ( magari dimenticarndosi di aggiornare qualcosa di strettamente collegato al db e....badabum!)
-- Anonymous coward
@ Alberto Di Anonymous coward postato il 24/12/2011 16:43
un numero simile di dati penso sia un'importazione da fonte esterna. Il beota che ha fatto, ne ha reimportarti un po per i suoi test e poi ha detto "per far prima" questi li ho gia' non li riprendo........
e che chissà che progettone se zappano via il 90% dei dati...
Tienili stretti questi personaggi perché ci rendono la vita allegra.
-- Anonymous coward
Di Rolando Francini postato il 24/12/2011 11:06
Faccio parte dei lettori "passivi", rompo il silenzio per augurare a Davide e a tutti i frequentatori, un felice Natale!
-- -liftman-
