Newsgroup: it.comp.lang.visual-basic
Titolo: [OT]: struttura database

volevo chiedervi un parere riguardo alla struttura di un database.
C'e' una ditta che ha 6 agenti e mi ha chiesto di fare un programma che
funzioni come un planning.
Il numero di agenti e' ovviamente variabile (nel senso che possono assumerne
di nuovi...)
Io ho pensato ad una tabella tblAgenti molto semplice:
ID_AGENTE  contantore
NOME_AGENTE testo
mentre per la tabella relativa al planning ho pensato a due alternative..
1a (tblPlanning):
DATA_APP
ORA_APP
DESCR_APP
ID_AGENTE
DURATA_APP
2a:
ORA_APP
DESCR_APP
ID_AGENTE
DURATA_APP
In questo caso non c'e' la data perche' pensavo di creare una tabella per
ogni giorno (ad es. tbl20021011)
Normalmente direi che il primo modo e' piu' corretto ma ho pensato che si
rischia, in poco tempo, di avere un'unica tabella mastodontica rallentando
moltissimo gli accessi... (siccome il database sara' access e non sql server
gia' avere poche migliaia di record e' scomodo da gestire...).
L'interfaccia che avevo pensato comprenderebbe un controllo monthview e una
griglia (planning) che visualizza gli agenti nelle colonne e come righe ha
varie fasce orarie:
             agente 1    agente 2    agente 3    agente 4
  9:00     ditta x                         ditta z
  9:30                      ditta z
10:00     ditta q                                        ditta u
Cliccando su un giorno del calendario il programma controlla se la tabella
relativa al giorno esiste.
Se esiste la carica nella griglia altrimenti viene creata la tabella e viene
visualizzata la griglia vuota...
Questo in breve sarebbe la questione...
Secondo voi e' piu' opportuno usare una tabella per ogni giorno o un'unica
tabella?
Oppure avete altre alternative?
tnx

 gia' avere poche migliaia di record e' scomodo da gestire...).
Più che scomodo potrebbe essere non prestante, con la seconda soluzione
comuqnue rischi di avere in pochi giorni diverse centinaia di tabelle da
gestire, veramente pesante per il codice!!
Prova  a fare un analisi di come saranno le query che vuoi fare sul Db e
guarda se ad esempio non converrebe dividere le tabelle sugli agenti ad
esempio (che saranno sempre meno dei giorni a meno che non ne assumano uno
al giorno).
Un altra idea, da valutare in realta in rapporto al uso che farai dei dati,
potrebbe essere fare due tabelle del tipo 1 da te proposto, in una cimetti
gli appuntamenti futuri e/o (e probabilmente consultati spesso) nell'altra
quelli passati e/o consultati meno spesso.
§Una sorta di cache insomma, anzi a pensarci bene in una ci potrebbero stare
tutti gli appuntamnti, nell'altra creaa al volo all'inizi del programma
quelli che hanno più probabilità di essere consultati.
Ovviamente il costo di tutto ciò è quello di mantenere la coerenza dei dati
contenuti nelle tabelle.

Ciao, anche io ho affrontato in passato lo stesso problema.
Sicuramente la prima soluzione è quella esatta. Per il problema del numero
dei record puoi svuotare la tabella periodicamente e buttare i record che
elimini dalla tabella principale in una tabella secondaria che ti serve come
archivio. Devi stare attento a gestire da codice l'evento di consultazione
di un appuntamento passato che sta sulla tabella archivio.
Buon Lavoro