Tales from the Machine Room


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

L'Hydra

Altro giorno, altro casino. Allora, ho gia' descritto alla nausea il mega- mastodontico- doppio cluster che usiamo per processare la posta. Adesso abbiamo deciso che e' il momento di aggiornarlo. In particolare vogliamo aggiungere un secondo antivirus al primo, aggiungere il famigerato controllo reputation based ed altre cosine varie. Ma soprattuto, vogliamo passare i server da Fedora 5 a qualche cosa di meno volubile ed un pelo piu' stabile. Tipo CentOs.

Il che significa che mi aspetta la reinstallazione di tutto l'ambaradam di 32 server nel prossimo futuro.

Il tipo che aveva installato il tutto (quello che tirava le tastiere dalla finestra e che ci ha lasciato di colpo), ha lasciato un po' di documentazione sparsa, ma non e' che vi sia molto da leggere, in particolare i vari "dettagli" sul come e perche' installare le cose sono molto nebulosi. Ed anche alcune delle sue scelte non sono proprio allineate con le mie. In particolare ritengo l'uso di daemon tools per la gestione dei servizi in vece del normale sistema di processi una gran rottura. Che finche' funziona va tutto bene, ma a me e' gia' capitato che uno dei processi si incatasti e daemon tool si incatasta pure lui e l'unica e' un bel riavvio.

In ogni caso, dato che voglio rifare il tutto, usare versioni aggiornate dei vari software eccetera eccetera, ho deciso di fare le cose per bene, quindi sono qui' occupato a mettere insieme un mega Kick-start file sul nostro server di installazione remota in modo che con un colpo solo mi installi l'intero server con tutto il software necessario pronto al lavoro. E poi aggiungere un piccolo, rapido e crudele script di autoconfigurazione che finisca il lavoro aggiungendo tutti i dettagli necessari, in modo che in una mezz'oretta mi ritrovo con un server pronto al funzionamento, invece di perdere due giorni per cercare ed installare tutti i pezzi che mi servono.

La destinazione e' fissa, la strada e' segnata, l'unico problema e' che il cammino e' una barbosa ripetizione di: installa, vedi che cosa manca, aggiungi al kickstart, modifica lo script di configurazione, reinstall, risciacqua, ripeti.

Mentre sono qui' che mi delizio guardando l'ennesima reinstallazione della macchina virtuale che non trova un qualche rpm, A si appropinqua.

Non ho ancora presentato A. Allora, lui e' un Network Administrator, cioe' si occupa per lo piu' di mettere insieme switch, router e roba simile e farli parlare tra di loro e con il resto dell'universo noto (e ignoto). Si occupa anche di alcuni firewall e di mantenere il nostro sistema di monitoring basato su Nagios.

IO - (segnandomi quali rpm mi servono) Che ti serve?
A - Ho un problemino con il backup dei router di un cliente.
IO - Che problema?
A - Allora, tu conosci vero il nostro database di configurazione?

Il database di configurazione e' l'ennesimo accrocchio in php scritto da una tipa (si' era donna) tempo addietro. E' una mostruosita' che mi ricorda l'Idra. Purtroppo, H era anche quello che si occupava di quell'arnese e quindi temo che, dopo avere ereditato il mailscan, sono in pista per ereditarmi anche questo di accrocchio.

IO - Si', lo conosco... che c'entra quel coso?
A - Allora, tempo addietro con H avevamo fatto un affare che prendeva gli indirizzi ip dei router dal database e preparava uno script per fare il backup via tftp dei router direttamente. In modo che c'era da mantenere un solo database invece che due. Solo che, per qualche motivo, ci sono alcuni routers che non entrano in quello script. Ed io devo aggiungerli a mano ogni volta.
IO - Interessante.
A - E quindi mi chiedevo, se tu non potessi spendere dieci minuti guardando perche' quei router non si trovano nello script.
IO - Che routers? Dove sta lo script? Come si crea?

A fornisce tutti i dati e, dopo essermi tappato il naso, mi metto a guardare anche questo problema.

Allora, i routers sono inseriti nel database di configurazione, che ha una struttura multi-livello. Ci sono "oggetti" che hanno "proprieta'". Ed ogni "oggetto" puo' essere in relazione con uno o molti altri "oggetti", il quale puo' essere a sua volta in relazione con altri "oggetti". E cosi' via, ad libitum.

Va bene cominciamo dall'interfaccia. Guardo uno dei router che sono nello script e guardo come e' definito. Allora, una delle "proprieta'" e' "backup" con valore "tftp". Ok. Poi c'e' un "oggetto" collegato che si chiama "interfaccia" ed ha l'indirizzo IP come una delle proprieta'. Ok. Facile.

Adesso vediamo uno dei famosi routers che nello script non c'e'.

E non ci trovo assolutamente niente di anormale. Esattamente come l'altro ha una proprieta' "backup", con lo stesso valore, ha un oggetto collegato... ummmm... pare tutto ok. Almeno, dal punto di vista dell'utente, e' tutto ok. Adesso si tratta di andare a vedere come viene creato questo script.

Scovo lo script di generazione dello script (sic) nei meandri del database server (si', quello in cluster-che-non-e'-un-cluster e che io ho iniziato a sostituire), ok, banale script in perl che fa una query... mooooomento... query???


select parent.name, object.name, p.value
from object
inner join property on property.object_id=object.id
inner join relation as rp on object.id=rp.object2 and rp.type='eigendom'
inner join object as parent on rp.object1=parent.id
inner join relation as ri on ri.object1=object.id and ri.type='interface'
inner join object as interface on ri.object2=interface.id
inner join property as p on p.object_id=interface.id
where property.value='tftp' and object.active=1
and p.value not like '192.168.%' and p.value not like '10.%'
and p.value not like '172.16.%' and p.value not like '172.17.%'
and p.value not like '172.18.%' and p.value not like '172.19.%'
and p.value not like '172.20.%' and p.value not like '172.21.%'
and p.value not like '172.22.%' and p.value not like '172.23.%'
and p.value not like '172.24.%' and p.value not like '172.25.%'
and p.value not like '172.26.%' and p.value not like '172.27.%'
and p.value not like '172.28.%' and p.value not like '172.29.%'
and p.value not like '172.30.%' and p.value not like '172.31.%'
and p.value not like ''
order by parent.name, object.name, p.value;
Questa non e' una query! Questa e' una dichiarazione di guerra!

Alura, taglia e incolla la query nella console di mysql e lui mi ritorna correttamente l'elenco dei routers che sono nello script. E perche' non mi ritorna quegli altri?

Mi metto percio' a vivisezionare le varie relazioni. Allora, la tabella "proprieta'" e' in relazione con "oggetti", la quale e' in relazione con "relazioni", la quale e' in relazione con "oggetti" (di nuovo) la quale e' in relazione con "proprieta'" (di nuovo)...

Dopo aver tirato una manica di accidenti alla tipa e ad H riesco a scovare il problema, la maledetta cosa cerca una relazione di tipo "eigendom" (che, credeteci o no, significa "proprieta'"), mentre, per qualche strano motivo, il router che non compare, la relazione l'ha di tipo "network".

Dopo essermi grattato la pera per una buona mezz'ora ed aver cercato di capire esattamente a che cappero servono i tipi di relazione, provo a cambiare il tipo nel db e rifaccio la query alla console.

Certo come il sorgere del sole, il router "mancante" appare nella lista.

Una rapida ricerca nei meandri del codice dell'interfaccia di questo database non mi ritorna nessuna spiegazione del perche' uno degli oggetti ha una relazione di un tipo e l'altro no. Quindi mi limito a cambiare i vari record che non compaiono ed a verificare che a) siano ancora riportati nell'interfaccia e b) compaiano nello script.

Butto giu' due note di documentazione sulla cosa ed informo A che il suo problema per il momento e' risolto.

Adesso, il prossimo passo nel mio (lungo) elenco di cose da fare e': proporre il rifacimento del maledetto database di configurazione. Possibilmente NON in php.

Davide
19/10/2009 08:00

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.

34 messages this document does not accept new posts
Argaarpeccato... By Argaar - posted 19/10/2009 09:10
>proporre il rifacimento del maledetto database di configurazione. Possibilmente >NON in php.

che peccato...e dire che mi stavo per proporre visto che ho finito giusto sabato il mio ultimo progetto...

certo che però te le vai a cercare...5 storie saranno su sto coso o sei riuscito a licenziarti prima di iniziarlo?

--
Argaar


Herr Franzgiusto! By Herr Franz - posted 19/10/2009 09:11

< giusto!
E sono certo che ti daranno ragione!
E ti chiederanno di farlo in assembler*....





*avrei detto visual basic ma il server non è win, quindi....

--
Herr Franz


PalinPHP By Palin - posted 19/10/2009 09:25

> Adesso, il prossimo passo nel mio (lungo) elenco di cose da fare e': proporre
> il rifacimento del maledetto database di configurazione. Possibilmente NON in php.

Probabilmente il problema non è del php ma stava tra la sedia e la tastiera... :\) :\)

--
Palin


Eugenio Dorigati@ Palin By Eugenio Dorigati - posted 19/10/2009 10:29

>select parent.name, object.name, p.value
>from object
>inner join property on property.object_id=object.id
>inner join relation as rp on object.id=rp.object2 and rp.type='eigendom'
>inner join object as parent on rp.object1=parent.id
>inner join relation as ri on ri.object1=object.id and ri.type='interface'
>inner join object as interface on ri.object2=interface.id
>inner join property as p on p.object_id=interface.id
>where property.value='tftp' and object.active=1
>and p.value not like '192.168.%' and p.value not like '10.%'
>and p.value not like '172.16.%' and p.value not like '172.17.%'
>and p.value not like '172.18.%' and p.value not like '172.19.%'
>and p.value not like '172.20.%' and p.value not like '172.21.%'
>and p.value not like '172.22.%' and p.value not like '172.23.%'
>and p.value not like '172.24.%' and p.value not like '172.25.%'
>and p.value not like '172.26.%' and p.value not like '172.27.%'
>and p.value not like '172.28.%' and p.value not like '172.29.%'
>and p.value not like '172.30.%' and p.value not like '172.31.%'
>and p.value not like ''
>order by parent.name, object.name, p.value;

la query più lungha che ho mai fatto è 1/4 se non meno di questa!
Buona giornata.

--
"Unix IS user friendly. It's just selective about who its friend are"


Anonymous cowardnon è il PHP, è il programmatore By Anonymous coward - posted 19/10/2009 09:30


non è lo strumento, ma come lo si usa...

il problema è che le riviste erano piene di articoli "diventa programmatore in 2 ore con php" e tutti si sono creduti ottimi sviluppatori !

magari qualche linguaggio ti forza ad avere approcci migliori ma il succo è quello: è la testa di chi scrive il codice il problema

--
Anonymous coward


R.P.ho mollato la storia a meta'... By R.P. - posted 19/10/2009 09:35

tanto ormai lo schema e' noto.

A. BigD cambia posto di lavoro
B. ah, che bello, faccio quello che mi piace.
C1. Collega_N sclera, molla il lavoro e BigD becca il padulo_N
C2. DaBOSS rifila Padulo2_N a BigD
C3. a BigD il nuovo lavoro piace sempre meno
D. Reiterare punti C1-C3 per K volte
E. quando K>Z bigD sclera e molla il lavoro, vai al punto A.

Direi che ora bigD e' al punto K=42....

--
R.P.


Anonymous coward@ R.P. By Anonymous coward - posted 19/10/2009 10:23

> Direi che ora bigD e' al punto K=42....

Quanto vale Z attualmente?

--
Anonymous coward


Golan Trevizepovero PHP By Golan Trevize - posted 19/10/2009 10:01

Non è tanto il fatto che PHP=cacca e altrolinguaggiofigo=oro... qua è un problema di cultura informatica.
Per qualche motivo, un numero notevole di gente che scrive(va) pagine html con dreamweaver e soci è stata dirottata a scrivere pagine in PHP, perché tanto son pagine html dinamiche (sic!).

E' molto facile incontrare sedicenti programmatori PHP che non ne sanno un tubo di programmazione e vengono dal mondo ormai obsoleto dei siti statici. Questo perché PHP sembra (e sottolineo SEMBRA) molto facile da imparare e usare per chi non ne sa nulla o quasi di programmazione.

Salvo poi regalare al mondo perle di ignoranza come quelle che ci narra il buon D.

In questo caso poi, 6 join in una query del genere (per non parlare del where!) fanno gridare vendetta. Se questo è il codice SQL mi immagino le perle del PHP!

--
Golan Trevize


Davide InglimaRegola numero uno del CL. By Davide Inglima - posted 19/10/2009 10:16

Un CL non impara mai dai propri errori.

> Adesso, il prossimo passo nel mio (lungo) elenco di cose da fare e': proporre
> il rifacimento del maledetto database di configurazione. Possibilmente NON in
> php.

Ooops.

--
http://limacat.blogspot.com


Anonymous cowardCi risiamo... By Anonymous coward - posted 19/10/2009 10:26

> ...
> Adesso, il prossimo passo nel mio (lungo) elenco di cose da fare e': proporre il rifacimento del maledetto database di configurazione. Possibilmente NON in php.


Di nuovo? Quando imparerei che tacere è meglio!

--
Chi si fa i cazzi sua torna sano a casa sua.

--
Anonymous coward


Diego E. Pettenò — FlameeyesPHP e sedicenti “programmatori” By Diego E. Pettenò — Flameeyes - posted 19/10/2009 10:54

Concordo sul problema di cultura… chi scrive in PHP il più delle volte non ha mai dovuto debuggare un programma, ma solo forzarlo a fare quel che gli serviva.

Poi si può tentare di discutere su quale sia il linguaggio migliore, ma credo che per tanti ormai PHP sia considerato taboo abbastanza…

P.S.: condivido il sentimento riguardo daemontools… mai più, mai più per me!

--
Diego E. Pettenò — Flameeyes


Riccardo Cagnassocentos? By Riccardo Cagnasso - posted 19/10/2009 12:13

Umm, ma io mi sono imbattuto in centos un paio di volte e l'impressione che ne ho avuto e' che fosse una schifezza bestiale, ma una schifezza oltre dire "a me piace questa distro a te piace l'altra", proprio una merda tout-court. A questo punto mi chiedo, come mai usate centos invece che usare debian come tutti i cristiani? Delle tre l'una:

1) Mi sono sbagliato e CentOS non fa schifo, magari sono io che non ci ho capito una sega.
2) L'hanno aggiornata e fa meno schifo.
3) E' particolarmente well-suited per quello che dovete fare voi, tanto da dire "mi tappo il naso e via".
4) Altre...

--
Riccardo Cagnasso


Davide Bianchi@ Riccardo Cagnasso By Davide Bianchi - posted 19/10/2009 12:19

> Umm, ma io mi sono imbattuto in centos un paio di volte e l'impressione che ne ho avuto e' che fosse una schifezza bestiale

E' esattamente come RedHat ma non devi pagare l'assistenza.

> A questo punto mi chiedo, come mai usate centos invece che usare debian come tutti i cristiani?
> Delle tre l'una:
>
> 1) Mi sono sbagliato e CentOS non fa schifo, magari sono io che non ci ho capito una sega.

Giusta la prima. Ci sarebbe da dirne anche un'altra ma se vuoi te la spiego in privato.

--
Davide Bianchi


Kesty@ Riccardo Cagnasso By Kesty - posted 19/10/2009 13:54

Sinceramente noi abbiamo tutti i server Linux con su CentOS e personalmente mi sono sempre trovato benissimo nonostante non mi considero particolarmente ferrato in ambiente Linux.

--
Kesty


z f k@ Riccardo Cagnasso By z f k - posted 19/10/2009 14:34

> Umm, ma io mi sono imbattuto in centos un paio di volte e l'impressione che ne ho avuto e' che

CentOS l'ho incrociato perche' una ditta di informatica (leggi cert MS) ha scoperto DimDim, che fa quello che chiede il cliente e non costa nulla per meno di 20 utenze.
Ora, se voi siete una ditta fondalmentalmente MS-centrica e vi trovate di fronte questo:
http://sourceforge.net/projects/dimdim/files/Dimdim%20v4.5%20Release/
cosa scegliete di fare?
Una banana al vincitore!
Esatto: vi scaricate l'immagine della macchina virtuale, prendete una macchina con su MSWin, installate VMWare e ci piazzate la suddetta immagine. Reiterare per ogni sede.

CYA

P.S.: un saluto a flameeyes e a Bosk (ma tanto sono in incognito hehehe) :D

--
z f k


TsumiQuery By Tsumi - posted 19/10/2009 18:46

La query più assurda credo di averla beccata io un po' di tempo fa...
Stavo guardando con un mio collega per ottimizzare un db MSSQL (100 gb di db, un centinaio di tabelle e dei join selvaggi su un server con 8 gb di ram ... che vuoi ottimizzare...?) e sul log delle query più frequenti ne abbiamo trovata una che era tipo:

SELECT campoA, campoB, campoC FROM tabella1 WHERE
userid = 'stringa_alfanumerica' OR
userid = 'altra_stringa_alfanumerica' OR
userid = 'altra_stringa_alfanumerica_ancora' OR
...
[riempite 30-40 schermate di OR simili]

Il "rapporto" di ottimizzazione alla fine è stato qualcosa tipo "riscrivete quella foxxuta applicazione"...

--
Tsumi


ringo@ Tsumi By ringo - posted 20/10/2009 10:27

> La query più assurda credo di averla beccata io un po' di tempo fa...
> Stavo guardando con un mio collega per ottimizzare un db MSSQL (100 gb di db, un centinaio di tabelle e dei join selvaggi su un server con 8 gb di ram ... che vuoi ottimizzare...?) e sul log delle query più frequenti ne abbiamo trovata una che era tipo:
>
> SELECT campoA, campoB, campoC FROM tabella1 WHERE
> userid = 'stringa_alfanumerica' OR
> userid = 'altra_stringa_alfanumerica' OR
> userid = 'altra_stringa_alfanumerica_ancora' OR
> ...
> [riempite 30-40 schermate di OR simili]
>
> Il "rapporto" di ottimizzazione alla fine è stato qualcosa tipo "riscrivete quella foxxuta applicazione"...
>

Vorrei spezzare una lancia!
Anche una delle mie query sta diventando come quella qui sopra.

Tutto era cominciato qualche anno fa quando bisognava estrarre dei record con un campo appartenente ad un ridottissimo insieme:

SELECT * FROM TABELLE WHERE CAMPO IN ('uno', 'due', 'tre');

A mia domanda se CAMPO nel tempo avesse potuto avere altri valori mi risposero $assolutamente_mai_impossibile_quelli_sono_quelli_restano!
tanto che gia' tre mesi dopo avevo dovuto aggiungere anche 'quattro' e 'cinque'

A quel punto chiesi se non era il caso di valutare di inserire quei valori in una tabella aggiornabile dall'utente e riscrivere la query con una join.
Mi chiesero "quanto costa?" non tanto per il costo del lavoro (siamo tutti interni) quanto perche' la creazione di una ulteriore tabella non prevista nella analisi (la parola "analisi" deve sempre essere accompagnata da una fragorosa grassa risata in sottofondo, come fanno i cavalli di Frankenstein Junior quando sentono il nome Blucker).

La tabella la devono creare $quelli_del_db, quindi costa, quindi non si fa, perche' non c'e' il budget. (siamo tutti interni, ma l'IT e' ripartito in $programmatori, $sistemisti e $quelli_del_db, tutti team diversi con budget separati)

E cosi' per non far fare una tabella a $quelli_del_db, la mia query e' gia' arrivata a CAMPO 'diciannove' e non e' ancora finita...



--
ringo


Tsumi@ ringo By Tsumi - posted 20/10/2009 11:48

> Vorrei spezzare una lancia!
> Anche una delle mie query sta diventando come quella qui sopra.
>
> Tutto era cominciato qualche anno fa quando bisognava estrarre dei record con un campo appartenente ad un ridottissimo insieme:
>
> SELECT * FROM TABELLE WHERE CAMPO IN ('uno', 'due', 'tre');
>
> A mia domanda se CAMPO nel tempo avesse potuto avere altri valori mi risposero $assolutamente_mai_impossibile_quelli_sono_quelli_restano!
> tanto che gia' tre mesi dopo avevo dovuto aggiungere anche 'quattro' e 'cinque'
>
> A quel punto chiesi se non era il caso di valutare di inserire quei valori in una tabella aggiornabile dall'utente e riscrivere la query con una join.
> Mi chiesero "quanto costa?" non tanto per il costo del lavoro (siamo tutti interni) quanto perche' la creazione di una ulteriore tabella non prevista nella analisi (la parola "analisi" deve sempre essere accompagnata da una fragorosa grassa risata in sottofondo, come fanno i cavalli di Frankenstein Junior quando sentono il nome Blucker).
>
> La tabella la devono creare $quelli_del_db, quindi costa, quindi non si fa, perche' non c'e' il budget. (siamo tutti interni, ma l'IT e' ripartito in $programmatori, $sistemisti e $quelli_del_db, tutti team diversi con budget separati)
>
> E cosi' per non far fare una tabella a $quelli_del_db, la mia query e' gia' arrivata a CAMPO 'diciannove' e non e' ancora finita...
>

Vabbè però un modo tecnico di risolvere il problema c'era, quindi possiamo dare la colpa alla gestione del progetto che per 4 soldi in meno ha fatto si che si producesse questo orrore piuttosto che ad un limite tecnico :D
Cmq qui si è arrivati almeno CAMPO 'tremila' che è un po' di più di 'diciannove' :|

--
Tsumi


Anonymous coward@ ringo By Anonymous coward - posted 21/10/2009 14:52

> La tabella la devono creare $quelli_del_db, quindi costa, quindi non si fa, perche' non c'e' il budget. (siamo tutti interni, ma l'IT e' ripartito in $programmatori, $sistemisti e $quelli_del_db, tutti team diversi con budget separati)
>
> E cosi' per non far fare una tabella a $quelli_del_db, la mia query e' gia' arrivata a CAMPO 'diciannove' e non e' ancora finita...

e fare una query tipo "SELECT * FROM TABELLE WHERE CAMPO IN ('uno', 'due', 'tre');CREATE TABLE nuova_tabella etc..." ?

--
Anonymous coward


alessiodpphp da' troppa liberta' By alessiodp - posted 19/10/2009 19:22

il php da' troppa libertà nell'uso delle variabili delle funzioni e degli interrupt...
pertanto si presta bene a piccoli algoritmi o piccoli script
alcuni lo usano alla menopeggio...
pazienza...

--
alessiodp


Golan Trevize@ alessiodp By Golan Trevize - posted 20/10/2009 11:18

> il php da' troppa libertà nell'uso delle variabili delle funzioni e degli interrupt...

interrupt? Tipo int13? Dove? :\)

> pertanto si presta bene a piccoli algoritmi o piccoli script
> alcuni lo usano alla menopeggio...

Il C dà molta più libertà. Puoi anche formattare gli hard disk o far resettare il computer. E riesci anche a spararti sul piede...

--
Golan Trevize


Davide Bianchi@ Golan Trevize By Davide Bianchi - posted 20/10/2009 11:34

> Il C dà molta più libertà. Puoi anche formattare gli hard disk o far resettare il computer. E riesci anche a spararti sul piede...

Anche col PHP riesci a spararti nei piedi. Solo che PHP e' un linguaggio molto gentile: ti spara prima lui in un piede per verificare che la pistola funzioni e poi te la passa cosi' puoi spararti nell'altro.

--
Davide Bianchi


LuciferSamquery da migliaia di righe By LuciferSam - posted 19/10/2009 20:25

eh eh, peccato che io ho visto query e stored procedures con migliaia di righe e non sono nemmeno identate decentemente... :\(

--
LuciferSam


Davide Bianchi@ LuciferSam By Davide Bianchi - posted 19/10/2009 20:42

> eh eh, peccato che io ho visto query e stored procedures con migliaia di righe e non sono nemmeno identate decentemente... :\(

Ma qualche cosa mi dice che non erano in MySql.

--
Davide Bianchi


Kent Morwath@ Davide Bianchi By Kent Morwath - posted 19/10/2009 23:40

> Ma qualche cosa mi dice che non erano in MySql.

No, infatti nessuno implementa un datewarehouse su MySQL ;P

A parte gli scherzi, in genere le query su sistemi OLTP sono piuttosto semplici (specialmente se lo schema è fatto bene) - quelle complesse di solito appaiono nei DW, specialmente se si fanno calcoli e aggregazioni direttamente nella query, che di solito è un po' più performante che spostare il 75% del database sul client per i calcoli.

Se si impara a ragionare a "set" invece che proceduralmente con SQL si possono creare query apparentemente complesse, ma che alla fine sono performanti e sfruttano appieno il motore DB. Però è anche facile pastrocchiare e scrivere decine di linee che ingarbugliano solo il tutto.

--
Kent Morwath


LuciferSam@ Davide Bianchi By LuciferSam - posted 20/10/2009 21:14

> Ma qualche cosa mi dice che non erano in MySql.

difatti SQL SERVER 2000 di Zia Microsoft

--
LuciferSam


Herr FranzAdesso che lo rileggo.... By Herr Franz - posted 19/10/2009 20:49

E' una mostruosita' che mi ricorda l'Idra.

Ma...a ricordarti l'idra era il database di configurazione o la tipa che lo aveva scritto?

(se la risposta era la seconda opzione , mi sa tanto che non avra' l'onore di venir aggiunta al vasto harem del visir D.B.)


--
Herr Franz


AndreaQuery MSSQL By Andrea - posted 19/10/2009 22:54

Per un cliente($VESTITI_FIRMATI_DAL_NOME_STRANO) di cui la ditta per cui lavoravo gestisce il world wide shop ed una serie di ammennicoli, ci sono delle stored procedure con queries... come dire... un pelino complicate :-\)
Al confronto, quella query è piccola.
Per non parlare di un certo programma in VB... un giorno questa la mando! :D

Andrea

--
Andrea


Kent MorwathAaaaah, il mitico database "generico" :-D By Kent Morwath - posted 19/10/2009 23:36

Eccolo un altro che ha deciso di implementare il mitico database universale - ogni database può essere implementato in sole 4 tabelle! Si gettano al vento i tipi (si usano solo campi generici stringa...) e altre amenità quali vincoli e integrità, per ottenere il dato più stupido si fanno ventisette join, ma una volta creato la schema non lo si tocca più! Vuoi mettere? :D

--
Kent Morwath


Angkarn@ Kent Morwath By Angkarn - posted 20/10/2009 11:47

> Eccolo un altro che ha deciso di implementare il mitico database universale - ogni database può essere implementato in sole 4 tabelle! Si gettano al vento i tipi (si usano solo campi generici stringa...) e altre amenità quali vincoli e integrità, per ottenere il dato più stupido si fanno ventisette join, ma una volta creato la schema non lo si tocca più! Vuoi mettere? :D
>
>

Proprio l'immagine che ha dato a me!
Di query ne ho viste e scritte anche di molto più lunghe, ma comunque molto più chiare. Mappare ogni oggetto reale con tabelle così generiche da obbligare i "query-writers" a fare filtro su un campo che specifica il tipo di relazione è follia pura. Peraltro, l'interminabile serie di filtri che va a includere o escludere gli indirizzi di determinate classi IP grida vendetta... sono le classiche query che richiedono manutenzione continua.
Purtroppo, ben pochi sanno come si progetta per bene un database.

--
Angkarn


Alberto2 cose By Alberto - posted 20/10/2009 00:48

Nella mia esperienza come sviluppatore ho visto query molto peggiori di queste.
E più che l'idra di Lerna, il lavoro di BigD (come spesso capita a tutti noi) mi sembra che consista nel ripulire le stalle di Augia.

http://it.wikipedia.org/wiki/Stalle_di_Augia

--
Alberto


GasQuery complesse By Gas - posted 21/10/2009 20:40

La query e' decisamente stata scritta da un folle, ma quando lavoravo (in subappalto) per $grossa_ditta_della_grande_distribuzione ho dovuto scrivere query decisamente piu' complesse.. e decisamente meno folli =P

--
-Gas-


StriderCambiare idea By Strider - posted 26/10/2009 20:28

Big D, scommettiamo che ti faccio cambiare idea sul "Possibilmente NON in php." ?
Pensa se fosse rifatto in JSP, dalla stessa programmatrice che lavorato sul codice precedente.
Non che sia un gran fan del PHP, ma sono un grande fan della defenestrazione degli incompetenti.

--
Strider


Davide Bianchi@ Strider By Davide Bianchi - posted 27/10/2009 08:38

> Pensa se fosse rifatto in JSP, dalla stessa programmatrice

Guarda che dopo aver visto quello che i phpiari fanno, sono pronto a chiamare gli 'slavi di $brancodipaguri "eccelsi programmatori".

--
Davide Bianchi


34 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