Newsgroup: it.comp.software.database
Titolo: tecnica bieca per velocizzare

ciao, ho un gran numero di record che sono referenziati attraverso circa 6
tabelle esterne. 
dato che vorrei avere una velocità sempre ottima (e sì, gli indici sono
fatti correttamente) ho creato dei campi direttamente nel record per
raccogliere i dati dalle varie tabelle esterne, con delle query che li
aggiornano in concomitanza agli aggiornamenti/delete/insert
ora è velocissimo in lettura, chiaramente le tabelle esterne mi servono per
fare le ricerche sui record e sembra tutto molto coerente.
mi chiedo se qualcuno ha mai usato questa tecnica o se è deprecabilissima.
peraltro, secondo voi è peggio creare delle sessioni PHP anche piuttosto
grandicelle per raccogliere degli array (e su questi fare dei calcoli con
PHP) o conviene comunque lavorare sempre con i dati dal Db?
grazie
-- 
Vedo gli amici ancora sulla strada, loro non hanno fretta,
rubano ancora al sonno l'allegria all'alba un po' di notte:
e poi la luce, luce che trasforma il mondo in un giocattolo.
Faremo gli occhiali così, Faremo gli occhiali così!

 deprecabilissima.
Beh, non direi che č "il male assoluto", ma devi tener presente alcune
considerazioni negative:
1. Cambiando la struttura delle tabelle rischi di intaccare la
correttezza dello schema logico (es. attributi che non stanno nelle
giuste tabelle, doppioni...).
2. In effetti stai "ottimizzando" lo schema nei confronti di un tipo
di query, ma contemporaneamente penalizzandone un altro tipo. Sei
sicuro che le esigenze del db non cambieranno mai?
3. Devi assolutamente ricordarti di "intercettare" i cambiamenti che
risulterebbero in dati desincronizzati; il risultato č che adesso il
db č sostanzialmente piů fragile, e se crediamo alle leggi di Murphy...
L'ideale sarebbe che queste ottimizzazioni vengano fatte nel physical
layer, piuttosto che nelle tabelle, in modo da non cambiare la logica
di manipolazione delle tabelle; ma purtroppo i dbms Sql storicamente
hanno la mappatura 1:1 righe -> record.
Ciao

 Ciao
-- 
Vedo gli amici ancora sulla strada, loro non hanno fretta,
rubano ancora al sonno l'allegria all'alba un po' di notte:
e poi la luce, luce che trasforma il mondo in un giocattolo.
Faremo gli occhiali cosě, Faremo gli occhiali cosě!

 grazie per la tua risposta.
In un rdbms "ideale", l'apparenza dei dati (es. lo schema) è
completamente disgiunto dal formato di memorizzazione su disco; in
tale db, potrei avere due "schemi": uno logico, visibile agli utenti
e soggetto a tutte le regole formali che conosciamo (normalizzato,
stabile, esente da anomalie, formalmente corretto etc etc), e poi uno
"schema" fisico, in cui il dba può giocarsela come vuole (tabelle
denormalizzate, ridondanti, partizionamenti orizzontali o verticali,
schemi olap, colonne a densità variabile, attributi che esistono
solo nel passato, repliche, cluster e tutto quant'altro si rendesse
necessario al momento).
Qual è il succo della questione? Che gli utenti e i programmi saranno
schermati dai dettagli implementativi del db, e otterranno sempre la
stessa visione sui dati anche se il dba cambia a piacimento la
disposizione su disco, mentre il motore del db gestirà in maniera
automatica il corretto aggiornamento delle tabelle.
Invece cosa hanno fatto storicamente i produttori? Hanno sostanzialmente
fissato, chi più chi meno, una corrispondenza diretta (definita anche
"direct imaging") tra una riga (concetto logico) e un record (concetto
fisico), una colonna = un campo; attualmente il dba ha ancora scarso
controllo sul livello fisico (e più il dbms è semplificato, più la
corrispondenza è marcata).
Il modello relazionale non prescrive nulla su come i dati devono essere
memorizzati su disco, ed è proprio tale intenzionale silenzio che è
la forza del RM, perché si traduce in libertà di implementazione.
Ad esempio, qualcuno ha fatto un motore di db che non memorizza i dati
a record, ma a colonne con link alle celle adiacenti; la particolarità
è di avere dei join velocissimi, e risolvendo guarda caso anche il tuo
tipo di problemi.
Un altro produttore ha preso e modificato pesantemente un prodotto
commerciale (mi pare Sql Server) per la costruzione automatica e
sempre online di cubi olap e di indici e gerarchie su ogni colonna,
eliminando la necessità di gestire database separati!!
Ciao
PS: abbiamo bisogno di prodotti migliori, le cose sono ancora distanti
dallo stato dell'arte... :-(

 :
|| immagina un sito in cui circa l'80% degli utenti esegue letture e
|| deve essere molto veloce. chi fa gli inserimenti è leggermente
|| penalizzato come tempi di attesa. però sostanzialmente l'utenza
|| rimarrà sempre questa
Probabilmente la % è molto più alta,considerando anche
accessi "statistici" (crawler) che impegnano fortemente
i database ; aggiungo anche che con la tua ottimizzazione
diminuisci il carico di lavoro per accessi simultanei.
Ho usato lo stesso principio della tua tecnica e
devo dire che mi ha dato buoni risultati.
Ciao
Luke

 Luke
-- 
Vedo gli amici ancora sulla strada, loro non hanno fretta,
rubano ancora al sonno l'allegria all'alba un po' di notte:
e poi la luce, luce che trasforma il mondo in un giocattolo.


 direttamente nel record.
Io non li invidio: violano una delle regole fondamentali dei database
relazionali.
ciao

 ciao
-- 
A sto mondo bisogna adatarse, o inrabiarse, o desperarse.