Newsgroup: it.comp.os.linux.sys
Titolo: consiglio gestione db

vi chiedo un consiglio, visto che tra poco devo passare
all'implementazione dalla fase i progetto.
allora ho un db mysql con diverse tabelle (sai che novità!), una delle
quali in una fase iniziale avrà un discreto numero di record inseriti
quotidianamente.
Col passare del tempo questo numero è certo che aumenterà notevolmente
(fino a diventare migliaia/decine di migliaia), quello che chiedo è come
gestire questa tabella senza far diventare le query di
selezione/inserimento troppo esose col l'aumentare del numero dei record.
Ho chiesto consiglio  a piu' persone , questi sono stati i risultati:
1 - decidi un arco temporale bello lungo (es 10 anni), crea
preventivamente un numero di tabelle associate a periodi di tempo da
decidere (un giorno-una , due - tre-quattro settimane)
e poi ripensare al tutto quando sarà scaduto l'arco di tempo coperto
2 - scrivere i record sempre in una e periodicamente costruire da questa
una tabella "storico" associata ad un certo periodo (da decidere),
svuotando quella dove si inserisce. Questa seconda opzione mi sembra piu'
ordinata (anche da un punto di vista del codice che non deve calcolarsi il
nome della tabella dove scrivere), pero' a differenza del primo metodo
vedo delle criticità nel momento del backup/svuotamento della tabella
principale. di certo in quel momento dovrei arrestare le applicazioni che
ci scrivono, o comunque mettere in lock la tabella etc.
che ve ne pare? 
avete consigli, soluzioni alternative?
ho scritto solo fesserie? O_o
da quello che ho capito mi sarebbe molto di aiuto questa nuova feat
introdotta in mysql 5.1 , ma non posso usarlo (e cmq è ancora data in
via di sviluppo anche li)
http://dev.mysql.com/doc/refman/5.1/en/partitioning.html
grazie

 (fino a diventare migliaia/decine di migliaia), quello che chiedo è come
se la tabella/db sono disegnati con intelligenza e usando gli indici in 
modo valido, non ci sono problemi nemmeno con milioni di righe..
per test, in azienda abbiamo esportato il magazzino di una anzienda 
(anni di movimenti, circa 1 milione di righe) da as400 a mysql
senza indicizzazione una semplice select ha impiegato quasi 20 secondi 
(su hw non molto prestante, un portatile).. dopo l'indicizzazione come 
su l'as, la stessa query è stata eseguita in qualche decimo di secondo.. 
appena il doppio del tempo che ci mette l'as.
quindi non farti seghe mentali :-)
progetta bene il db e fai un uso accorto degli indici..
ciao
Stefano

 Stefano
Quoto in pieno e aggiungo anche un'altra cosa.
Sicuramente avrai sentito che le join tra tabelle sono una delle cose
per cui non ci si deve preoccupare perché ci pensa il dbms.
Falso!
Il dbms cerca di metterci del suo cercando di ottimizzare le join, ma
non può fare né miracoli, tantomeno leggere la tua mente per capire
quello che vorresti fare. Alcuni dbms (come oracle, non credo mysql)
utilizzano anche dati statistici per cercare di ottimizzare le query
(caratteristica che viene quasi sempre cassata in fase di installazione
perché può portare a inpredicibilità nel comportamento dell'ottimizzatore)
Una stessa query può essere scritta per impiegare millisecondi con
milioni di record o minuti con centinaia di record.
Anche qui un progetto dello schema fatto con raziocinio (uso di chiavi
primarie, indici, foreign key, ecc) aiuta molto.
Quello che descrive l'OP nel punto n°2 (le view materializzate) vanno
bene su dati che vengono scritti una volta e letti migliaia di volte.
Infatti nei dbms le operazioni di cancellazione/scrittura/modifica sono
molto pesanti (specie se si eccede con l'uso degli indici).
La lettura di una tabella contro l'esecuzione di una join è molto più
leggera. Bisogna valutare quanto sia il tempo macchina che si spende per
la creazione della view materializzata (e se si può fare a sistema
"scarico") contro il tempo che occorre per eseguire ogni volta le join.
Consiglio di verificare il planning per tutte le query che si intende
eseguire (premettendo il comando EXPLAIN alla query e verificando quello
che il planner ha intenzione di fare. Index scan => OK, Sequential scan
=> Male per tabelle grandi)
PSK

 => Male per tabelle grandi)
grazie mille, ne faro' tesoro!

 grazie mille, ne faro' tesoro!
Prego e spero di non aver creato confusione.
PSK

 Prego e spero di non aver creato confusione.
in una parola , "disarmante" :)
c'è da studiare , e tanto.
daltronde, c'è sempre una prima volta
grazie veramente per le dritte.

 c'è da studiare , e tanto.
Benvenuto nel mondo dei RDBMS :)
Enrico
P.S. prova a cercare informazioni anche sul partizionamento delle
tabelle, ti conviene