Newsgroup: it.comp.software.database
Titolo: Risistemare il database

Salve è da tempo che ho questo dubbio:
Allora immaginando una situazione  in cui si ha un database che lavora ogni
giorno con un grossa quantità di dati
e ipotizzando che sia composto da una 40ina di  tabelle tutte legate da
relazioni ecc.
Quindi ogni giorno in queste tabelle vengon inseriti n record 100-200-300
ecc.
Vorrei sapere questa situazione per quanto può continuare ? mi spiego meglio
impotizzando di fare uno "zoom" su una tabella
ad'esempio tabella schede (magari è un db di un callcenter)
vediamo che ha tanti campi è il primo fra questi è l'ID, un indentificativo
univoco che ogni volta viene incrementato di 1
questo ID a quanto può arrivare come valore (logicamente dipende dal
database ) ma quandoi arriva al limite
che si fa ?
si butta il database ?
o si deve fare qualcosa prima  ?
Spero di essermi spiegato grazie a tutti ciao

 relazioni ecc.
Quando si progetta un database, occorre tenere conto di come questo
verra' utilizzato. Se hai un processo che inserisce i dati in maniera
automatica devi tenerne conto e stabilire come tali dati verranno
manipolati e cosa fare quando non ti servono piu'.
Fa' tutto parte del processo di analisi del db 'a tavolino'.
Davide
-- 
| A copy of the universe is not what is required of art; one of the
| damned things is ample. -- Rebecca West 
| 
| 

 ha scritto nel messaggio
news:2kmqt2F...@uni-berlin.de...


 arriverà o no ? )
No.
Se ci arrivi è perchè c'è stato un errore di progetto o di previsioni da
parte del progettista.

 ha scritto nel messaggio
news:93wFc.570770$rM4.23...@news4.tin.it...


 Dove pecca il mio ragionamento?
Se non valuti i volumi, la destinazione e gli scopi della tua tabella è
impossibile dare una risposta.
In linea di massima:
nel caso di tabelle con volumi di record costanti devi necessariamente
utilizzare un database in grado di gestirli.
nel caso di tabelle con volumi di record cumulativi avremo un punto critico
di collasso del database che dipende dalla quantità di dati che la tabella
può gestire e dal volume degli inserimenti su quella tabella quindi o agisci
sui due parametri in modo che questo punto critico venga raggiunto solo
(molto) dopo la morte del software oppure ti riconduci al punto precedente
limitando il volume di record gestibili dalla tabella prevedendo un sistema
che elimini le informazioni obsolete e sposti altrove le informazioni meno
utilizzate.

utilizzate.
sto incominciando a capire allora punto dove posso trovare informazione su
questi argomenti ?
potresti farmi un'esempio concreto
grazie R.


 potresti farmi un'esempio concreto
Per esempio puoi serializzare.
Poni caso che una azienda deve tenere archiviato un log di una certa
attività il più completo possibile, ad esempio  gli ingressi e le uscite dei
suoi dipendenti.
L'azienda non ammette la possibilità di eliminare dei dati, tu ti fai due
rapidi calcoli e scopri che dopo tre anni di attività la tabella in
questione raggiunge il massimo.
Tuttavia dopo una ulteriore analisi si scopre che ad essere usati
frequentemente sono solo i dati entro i sei mesi, quelli più vecchi vengono
usati molto raramente.
Allora decidi di mettere nella tabella del database solo i dati relativi
agli ultimi sei mesi, quelli più vecchi li serializzi periodicamente in una
collezione di file e prevedi un meccanismo per il recupero.
Sono solo idee campate in aria, bisogna analizzare il problema specifico per
trovare una soluzione; se posti il problema il newsgroup ti può aiutare su
quello.

 >


 fisico c'è dovuto
Perché?
Parti dal presupposto che
a) Non ci sia mai sfoltimento dei dati, cosa che potresti prevedere anche
    a tavolino.
b) I dati non vengano mai cancellati
c) Il limite fisico esiste, ma tu hai parlato di 300 record al giorno
    che anche non conoscendo la mole del singolo record non sono
    una quantità spropositata.
    danilo

 quello.
Non è vero che sono idee campate in aria, la logica è giusta è ovvio
che bisogna considerare il caso singolo particolare.
Il database ha comunque bisogno di manutenzione, perché progettarlo
alla perfezione non è possilbile.
Per fortuna i dabase hanno ancora bisogno dei dba.
    danilo

 wrote in message
2m9666F...@uni-berlin.de...

Era una discussione un po' vecchiotta cmq grazie del contributo.
Il mio era solo un esempio, senza il problema specifico si potrebbero fare
un numero infinito di esempi, ma non è detto che poi, per quanto corretti,
questi si rivelino anche utili.