Newsgroup: it.lavoro.informatica
Titolo: Database e query, quale il giusto equilibrio?

Ciao a tutti.
Vi pongo un argomento di discussione che c'entri un po' più col
newsgroup ed un po' meno con i soliti flame.. se posso!
Mi capita spesso di gestire progetti in cui devo decidere sia la
struttura del database che poi l'interazione con l'applicativo, che
questo sia un semplice client windows o che sia in congiunzione con
altri applicativi web, gestionali, ecc.
Normalmente procedo con la progettazione del database, come un mio
vecchio docente universitario insegnava ("prima un database ben fatto,
poi il resto.."), il che mi porta spesso a ridurre al minimo
indispensabile, spesso un insieme vuoto, la ridondanza dei dati, con
un numero decisamente alto di tabelle da consultare con molteplici
join.
Il tutto va integrato con una parure di viste che rendano le query
lato codice il più snelle possibile.
Questo però in alcuni casi comunque porta ad un appesantimento della
computazione del dbms, soprattutto quando i record diventano svariate
centinaia di migliaia.
E quì è l'argomento del post: vi capita e come lo affrontate, per pura
questione di prestazioni, di dover accettare un peggioramento della
struttura del database, per poi avere miglioramenti nella risposta
alle query?
Spero di essere stato chiaro..
Buona giornata,
Gianluca

 centinaia di migliaia.
Sei stato chiarissimo. Condivido praticamente in toto il tuo approccio,
e personalmente - ma sono pronto a essere bastonato - non ho dubbi
nemmeno circa quanto riporto qui sopra.
Lavoro del DBMS è, appunto, fare il DBMS e gestire in modo opportuno
grandi moli di dati, e compito di un DBA è proprio quello di
ottimizzare il tutto in modo che il compito del DBMS sia svolto nel
modo più efficiente possibile. Questo implica anche la questione
hardware in accordo col sistemista, ovviamente, non solo quella
software.
Io penso che sarebbe un errore mascherare difficoltà del DBMS con
accrocchi lato client, a meno che non sia strettamente necessario e/o
consigliabile (strutture pregresse), non fosse altro perché quanto meno
trasferiresti la eventuale pesantezza computazionale a un
appesantimento della rete (se devo fare 50 queries invece che una,
magari snellirò la gestione del DBMS, ma aggiungo 49 round trips che
potrebbero e dovrebbero essere evitati).
-- 
Ciao!
Luca


Prima di mettere mani al DB per denormalizzarlo un po' bisogna essere
sicuri del perché una certa query viene reputata lenta, anche perché poi
il mantenimento corretto di dati ridondanti è un'attività che comunque
deve impiegare del codice, quindi dovendo spendere del tempo a fare
qualcosa forse è meglio capire davvero il perché una query sia lenta.
Dalla domanda che fai mi pare che tu dia per scontato che tutta l'attività
di monitor del server + del servizio SQL sia già stata fatta, compreso lo
studio dei piani di esecuzione delle query pesanti per verificare se con
un'indicizzazione diversa le performance possano avere un certo
miglioramento. 
Solo con questi dati in mano poi puoi decidere di mettere mano alla
struttura del DB per duplicare un po' di qua e un po' di la alcuni campi
per rendere di conseguenza le query meno pesanti.
Ciao, Alessandro
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 poi il resto..")
Premessa: non prenderlo come un attacco personale!!
Questo e' il modo in cui si lavorava prima della diffusione della
programmazione ad oggetti (lo dici anche tu "un vecchio docente
universitario).
In uno scenario moderno in cui si faccia davvero OOP (e potremmo
disquisire giorni solo su questo punto) partire dal db non ha senso
semplicemente perche' un domain model ad oggetti non ha nulla a che vedere
con un modello relazionale.
E' come progettare un sistema per memorizzare dei triangoli, sviluppare un
sacco di quadrati e poi fare un sacco di "schifezza" per far entrare i
quadrati nella forma fatta per i triangoli.
Io parto dal domain model (up-front o incrementalmente e' un altro
discorso) e il fatto che alla fine verra' memorizzato in un db relazionale
viene dopo. Una volta che il modello ad oggetti esiste mi preoccupo di
come memorizzarlo al meglio (e quindi, se devo usare un db relazionale, a
come strutturare le tabelle, normalizzare o denormalizzare, etc, etc).
Il mio lavoro come sviluppatore e' sviluppare un applicazione e il DB e'
solo un aspetto se vogliamo spesso anche marginale, di pura memorizzazione
che nulla ha a che vedere con quello che l'applicazione deve fare per
l'utente (o se vogliamo quello che l'utente deve fare con l'applicazione).
I miei 2 centesimi di euro
Luigi



Chissà come mai la maggior parte degli applicativi per gli utenti sono
ritenuti lenti, eh? :-)
Ciao, Alessandro


 ritenuti lenti, eh? :-)
la fonte di questa "maggior parte"? la maggior parte di tutti gli
applicativi mai realizzati? dei fat-client? thin client? web application?
delle applicazioni sviluppate da te o da altri? e sono ritenuti da chi? 
Ma soprattutto se si insegna da sempre di partire dal db e comunque "la
maggior parte degli applicativi per gli utenti sono ritenuti lenti" forse
che il motivo non e' specificamente quello ma semplicemente che la
"maggior parte degli applicativi" sono scritti male? ;-)
Luigi



E non è che la parte scritta "più peggio" è quella relativa agli accessi
al DB che è stato fatto con i piedi? :-)
Ciao, Alessandro


il 19/04/2007 12.44, Scrive Gianluca 40718184:

Pur avendo le prestazioni il loro peso, non ridurrei tutto a questo.
Sul fatto di ridurre al massimo la ridondanza dei dati, per esempio, non 
sono del tutto d'accordo. Per esempio va sicuramente normalizzato tutto 
cio' che riguarda l'integrita' del db ovvero tutte quelle tabelle per i 
referential constraint, ma sulle tabelle "finali" non ci trovo dei 
vantaggi se non quello di ridurre le dimensioni delle tabelle, con lo 
svantaggio che sono probabilmente quelle con il maggior numero di 
accessi e che provocano il maggior numero di regressioni, per cui se 
queste ultime vengono denormalizzate non viene minata l'integrita' e ne 
beneficiano i progarmmi che producono delle liste denormalizzate, che 
altrimenti dovrebbero farlo tramite join in cascata.
-- 
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

 denormalizzare, etc, etc).
Permettimi di essere d'accordo fino a un certo punto. Quando hai a che
fare con grosse moli di dati (uno o anche due ordini di grandezza
rispetto a quanto detto all'inizio) la progettazione della base dati è
centrale. Non puoi permetterti di relegare il suo concepimento al
termine del giro. Quindi, OK tutto il resto, e ci mancherebbe, ma guai
a sottovalutare il progetto della base dati.
-- 
Ciao!
Luca

 al DB che č stato fatto con i piedi? :-)
puo' essere ma la parte di accesso al db e' proprio quel layer intermedio
a cui mi riferivo io, non e' il db in se e per se :-)
Il "problema" nel partire dal db e' che la struttura dati decisa a priori
forzera' e limitera' le scelte in fase di sviluppo e spesso per risolvere
il problema il layer di accesso ai dati sara' infarcito di schifezze
proprio far fare qualcosa che non era stato previsto in fase di
progettazione del db.
Non sarebbe meglio isolare le due cose, avere l'applicazione che fa quello
che deve e poi vedere come meglio ottimizzare il db di conseguenza?
Luigi


 ritenuti lenti, eh? :-)
Beh, te lo dico io, perché un buon 70% di chi li sviluppa non ha mai
sentito parlare di SQL...
-- 
Ciao!
Luca

 a sottovalutare il progetto della base dati.
assolutamente non da sottovalutare, la progettazione del db e'
importantissima e ritengo per questo che dovrebbe evolvere con l'evolversi
dell'applicazione, non essere statica cosi come decisa a priori. Pero'
progettare e' una cosa, ottimizzare e' un altra e, permettimi di
aggiungere, la mole di dati e' importante ma se non lo fosse non userei un
DBMS che, si suppone, fa bene proprio quello: gestire grosse moli di dati.
Ciao


 Ma soprattutto se si insegna da sempre di partire dal db e comunque
No, Luigi, per carità, ma MAGARI si prendesse in considerazione quel
povero Cristo di DBMS!!! Si eviterebbero tanti casini che ho visto (e
qualche volte che ho fatto, confesso) per non conoscere l'esistenza di
costrutti appositi.
-- 
Ciao!
Luca

 Luigi
Ah! il solito guga-guga che lavora per un pugno di mosche... ;-)
Buona giornata,
Gianluca

 costrutti appositi.
Certo.
Dato l'OP e il gruppoo pero' il mio post partiva dal presupposto che "noi
sia bravi (perche' abbiamo fatto i nostri casini anni fa) quindi assumendo
questo non sarebbe meglio bla bla bla invece che bla bla bla?" :-)



Di solito è molto difficile che si cambi radicalmente la struttura del
db
quando l'applicazione è realizzata. Infatti in caso contrario
bisognerebbe
riscrivere ampia parte del codice.
Semmai si cerca di ottimizzare le query e/o il codice stesso.
Certo che se normalizzi creando per esempio 2 tabelle che vengono
sempre accedute
in join e mai da sole, vuol dire che non hai pensato per nulla alle
prestazioni. E questo è sempre male.

Luca Menegotto ha scritto:

Io aggiungo anche per la non conoscenza di un approccio orientato al
dataset, quando per "abitudine" si tende sempre a lavorare riga per riga
con loop enormi e spesso inutili, e che in ogni caso ammazzano il server
SQL.


 alle query?
La domanda non ha senso.
Se la struttura e' fatta al meglio, le query vanno meglio possibile,
no?
Piero

dipende cosa intendi con fatta la meglio. Formalmente fatta al meglio
sarebbe "che segue tutte le regole di normalizzazione" ma, ad esempio,
denormalizzare e' bene in diverse situazioni. In quel caso una base di
dati denormalizzata non e' fatta al meglio ma va il meglio possibile.



Scusa e gli ORM?
Comunque gli stessi problemi li hai anche quando progetti il tuo data
model ad oggetti.
Se esageri con le relazioni e non organizzi bene le tue classi arrivi
ad avere gli stessi problemi di un DB relazionale (che spesso e`
quello che trovi sotto il tuo modello ad oggetti)

 quello che trovi sotto il tuo modello ad oggetti)
qui rientriamo nel fare le cose bene o male e prescinde dall'approccio db
prima o db dopo, o no?



Ti ripeto, per me fare un class diagram da usare con un ORM e definire
delle tabelle SQL
sono equivalenti (proprio in virtu` di quella M in ORM) ed entrambi
significano progettare bene la struttura di un DB.
Essenzialmente stiamo a parlare della stessa cosa.

Zuz wrote:
:: dipende cosa intendi con fatta la meglio. Formalmente fatta al meglio
:: sarebbe "che segue tutte le regole di normalizzazione" ma, ad
:: esempio, denormalizzare e' bene in diverse situazioni. In quel caso
:: una base di dati denormalizzata non e' fatta al meglio ma va il
:: meglio possibile.
Sotto l'aspetto delle prestazioni sicuramente. Sotto l'aspetto della 
certezza del dato
no. Ed un dato non certo č un dato inutile.
La denormalizzazione porta immancabilmente alla violazione della prima e 
seconda forma normale.
Saluti.

 delle tabelle SQL
chi ha parlato di class diagram? ;-) Io parlo di classi ed oggetti "veri",
implementati e funzionanti, non disegnini...


 diversi come gli indici, non sulla struttura dati.
se non sai di cosa parli non sei obbligato ad intervenire...


 certezza del dato no. 
Beh, è vero che denormalizzare come Dio comanda non comporta
l'incertezza del dato (i trigger sono li apposta); pure i sacri testi
di SQL che ho io, dopo avere detto tutto il bene della normalizzazione,
dicono che in taluni casi che vedono la velocità come un fattore
critico sia da derogare a questa regola.
-- 
Ciao!
Luca

 seconda forma normale.
Non e' sempre vero. Anzi ci sono casi in cui se non denormalizzi 
corrompi i dati storici.



Hai un esempio?
Ciao, Alessandro


 Ciao, Alessandro
L'imbarazzo. Per esempio un campo "prezzo di listino" in un record 
scritto quando il listino di riferimento era in lire mentre quello 
attuale e' in euro.



Ma se la tabella con il listino prezzi prevede la storicizzazione il
problema non si evita?
In tutte le tabelle che hanno bisogno di usare un prezzo di listino non
basta far riferimento alla chiave corretta per beccare la posizione
storica con il prezzo giusto?



Anche io.
Fatto sta che quando crei classi "vere" per istanziarle in oggetti
"veri" in realta` stai
sottintendendo un class diagram. Anche se non fai disegnini :)

 Ciao, Alessandro
Tutto e' possibile, io ho fatto un esempio in cui il listino non e' 
storicizzato fino alla data di riferimento di quel prezzo! :-)
Ma di esempi del genere se ne potrebbero fare moltissimi.
Servirebbe comunque sul record del prezzo la data del listino in vigore, 
perche' non puoi avere una foreign key basata su un range di data e il 
listino non cambia tutti i giorni, quindi avrei evitato il campo "prezzo 
di listino" ma avrei dovuto inserire un ulteriore campo "data del 
listino vigente".
Ma se vuoi possiamo complicare la faccenda dicendo che il prezzo e' 
espresso in USD dipendentemente dal listino storico in lire e dal cambio 
vigente alla data in cui il prezzo si è formato. Come vedi saresti 
obbligato ad avere una foreign key sulla data di cambio nella tabella 
dei cambi ed una foreign key sulla data del listino storico per cui il 
prezzo dovra' essere associato a piu' date (perche' una foreign key non 
puo' riferirsi a piu' di una tabella), la data del prezzo, la data del 
listino (perche' i prezzi si formano tutti i giorni mentre i listini no) 
e la data del cambio (perche' la tabella dei cambi potrebbe avere delle 
discontinuita' sulle date): a questo punto mi sembrerebbe logico 
domandarsi se e' piu' efficiente un db integro e perfettamente 
normalizzato o un db egualmente integro anche se parzialmente 
denormalizzato.



Le prestazioni sono un problema reale, che interessa al cliente nella
stragrande maggioranza dei casi reali.
La certezza del dato è un concetto astratto, che nella realtà può
venire
a mancare per un milione di motivi (ad esempio alterazione locale di
un
supporto dati), tra i quali motivi la denormalizzazione (fatta con
prudenza, ovviamente)
è tra gli ultimi.
Perciò...

Gianluca
Grazie, anche a te.
-
Remove STOPSPAM to contact me

Dr.UgoGagliardelli wrote:
:: Non e' sempre vero. Anzi ci sono casi in cui se non denormalizzi
:: corrompi i dati storici.
In quei casi non è denormalizzazione. In realtà stai gestendo un altro tipo 
di entità.

Dr.UgoGagliardelli wrote:
:: il 20/04/2007 9.45, Scrive AleTV 40599440:
::: Dr.UgoGagliardelli ha scritto:
:::
:::: Non e' sempre vero. Anzi ci sono casi in cui se non denormalizzi
:::: corrompi i dati storici.
::::
::: Hai un esempio?
::: Ciao, Alessandro
:: L'imbarazzo. Per esempio un campo "prezzo di listino" in un record
:: scritto quando il listino di riferimento era in lire mentre quello
:: attuale e' in euro.
Quella non č denormalizzazione. 

 alle query?
La risposta e' dipende dal dbms.
Per esperienza personale (3 anni su oracle e ora su PostgreSQL) una
query scritta da un programmatore in fase di sviluppo e' passibile di
notevoli miglioramenti nelle mani di un performance tuner.
Come cio' possa accadere dipende da un miliardo di fattori.
Fare tuning su un DBMS (che ottimizzi le query a costi o a regole) e'
sopratutto un fatto di "pelle" che si forma con l'esperienza di come
questi gestisce l'I/O, la memoria e sopratutto imparando a riconoscere
le castronerie che di solito scrivono in programmatori
:P
Cmq il tuo approccio IMHO resta sempre il migliore.
Ciao
Federico
--
Federico Campoli
PGHost, 
http://www.pghost.eu

 notevoli miglioramenti nelle mani di un performance tuner.
Non ho dubbio. Una volta ho scritto una stored procedure che impiegava
5 secondi per essere eseguita. All'epoca ho giudicato la cosa
accettabile, perché si trattava della generazione di una stampa
complessa. A inizio dell'anno scorso l'ho ripresa in mano, a causa di
una revisione richiesta, e mi sono messo le mani nei capelli!! Dopo di
che, mi son dato del cretino, l'ho riscritta da zero usando un po' di
cose che avevo imparato nel frattempo, e ora la stessa SP impiega meno
di un secondo a essere eseguita.
A proposito, come ti trovi con Postgres? Io sto pensando al suo impiego
in sostituzione di MSDE (e sta competendo con Firebird)...
-- 
Ciao!
Luca

 
Con PostgreSQL mi trovo alla grande.
L'80% delle cose che ho imparato su oracle le riporto pari pari su
PostgreSQL.
Firebird l'ho visto un po' ma la sua usbabilita' non mi ha entusiasmato
tantissimo anche se le sue caratteristiche sono veramente notevoli.
Se ti interessa a luglio stiamo organizzando il pgday dove faremo un po'
di presentazioni ed "evangelizzazioni".
Verranno anche alcuni sviluppatori dagli USA.
http://www.pgday.it
;)
Ciao
Fede


 
http://www.pgday.it
Mi interessa. Me lo segno e se ce la faccio un giro ci sta tutto.
Grazie per la segnalazione.
-- 
Ciao!
Luca