Newsgroup: it.comp.appl.access
Titolo: Progettazione Nuovo DB

Buonasera a tutti i partecipanti,
debbo progettare un nuovo DB,
e vorrei chiarito un concetto:
E' meglio creare un db con tante tabelle??
(Sapendo già che fra due anni supererà i 2 GB)
O tanti DB in cui ognuna contiene una tabella??
(Tanti db per quante sono le tabelle)
Ed avvalorando questa seconda ipotesi,
il sistema potrebbe essere rallentato, considerando
che andrebbe a lavorare su svariate tabelle???
Mi auguro di aver reso l'idea e ringrazio a chi mi
darà delucidazioni in proposito.
Saluti Napoleone

 ha scritto nel messaggio
news:98p1c.48757$FJ6.1...@twister1.libero.it...

Se ti dicessi che l'approccio è completamente errato commetterei
un'errore, poichè non conosco il tuo progetto, pertanto la mia
risposta sarebbe affrettata e "forse" fuori luogo.
Considera però che solitamente non è il metodo corretto per
affrontare una progettazione di un Database, la struttura tabellare
Relazioni comprese deve risiedere nello stesso corpo(BE)
se devi, per ragioni di ingombro spezzare i BE non si dovrebbe
operare sulla singola Tabella, ma con un criterio mirato.
Potrebbe essere un'esempio l'anno solare(01/01/2004-31/12/2004)
Ovviamente si darebbe la possibilità all'utente di impostare a priori
lo sazio temporale di lavoro.....!
Questo premesso, la tua considerazione andrebbe supportata
da spiegazioni più di dettaglio in merito alla modalità di utilizzo
del DATABASE, dalle tue parole potrei pensare si tratti di un'applicazione
MONOTABELLARE (Un foglio di EXCEL per capirci........)
Ciao.
@Alex.

 ha scritto nel messaggio
news:c25e5t$t0$1...@lacerta.tiscalinet.it...

Grazie Alex, cercherò di spiegarmi meglio con esempio:
Attulmente ho il mio db Servizi.mdb in cui ho, oltre alle form,
query, report, moduli, le seguenti tabelle:
(relazionate correttamente)
Tb_Principale
In cui metto il numero, la data dei servizi e l'operatore;
ad ogni record della Tb_Principale, può corrispondere
uno o piu record (campi tipo memo con notevoli dati da inserire)
nelle tabelle sottostanti
Tb_1;
Tb_2;
Tb_3;
Tb_4;
Tb_5;
Tb_6;
Tb_7;
Tb_8;
Tb_9;
Tb_10;
ecc...
Quindi pensavo che:
la servizi.mdb sarebbe diventato Principale.mdb
con tutte le query, report, tabelle,che sono PERO' COLLEGATE
rispettivamente:
Tb_1  a Tb_1.mdb
Tb_2  a Tb_2.mdb
Tb_3  a Tb_3.mdb
Tb_4  a Tb_4.mdb
Tb_5  a Tb_5.mdb
Tb_6  a Tb_6.mdb
Tb_7  a Tb_7.mdb
Tb_8  a Tb_8.mdb
Tb_9  a Tb_9.mdb
Tb_10  a Tb_10.mdb
ecc...
Tutto questo per superare lo scoglio dei 2 GB.
Cosa mi dici adesso??
Ciao Napoleone

 ha scritto nel messaggio
news:bas1c.49250$FJ6.1...@twister1.libero.it...

Non è sufficiente, nel senso che non è comprensibile
la struttura, ipotizzo un'errore di fondo, ma è solo una
supposizione.
Mi spiego meglio:
Com'è possibile che ad 1 Tabella Principale possano
essere relazionate 10 Tabelle con relazione 1--Molti..??
I dati sono gli stessi, lato molti avrai sempre dati da legare
alla chiave della principale...??Se SI non ne vedo il senso
se NO non ho capito la tua spiegazione.......!
Porta pazienza, ma non voglio risponderti in modo frettoloso
pertanto se riesco a farmi un'idea del perchè di una struttura
forse un pò anomala, potrei esserti più di aiuto.
In modo asettico invece potrei indirizzarti verso MSDE
che, non ha il limite dei 2MB, è in modo Nativo agganciabile
ad un progetto ADP, permette di evitare lentezze dovute
alla tipicità dell'utilizzo di JET......!(Valuta seriamente
questa possibilità).
Ciao.
@Alex.

 @Alex.
Porta un po di pazienza, ma per me è importante capire
quanto stimo trattando. Oltre tutto c'è la possibilità
che il programma venga messo in rete locale su 3-4 PC,
quindi, pensavo che col crescere dei dati memorizzati,
il sistema.... collasserà??
Napoleone


Velocemente, mi sono letto alcune informazioni,
mi pare di capire che, oltre alle caratteristiche del db,
sia il caso di fare un Upsize del programma e quindi
migrare verso SQL Server??
Ciao Napoleone

 wrote in message
news:WhC1c.46954$
Kc3.1...@twister2.libero.it
Il discorso della MEGA_TABELLA è molto più adatto nel
caso sia rispettato il criterio di normalizzazione dati.
MSDE è una versione LIMITATA(nel numero di utenti contemporanei)
di SQL_SERVER, è già contenuta nel pacchetto di OFFICE_XP
addirittura se non sbaglio ci sono promozioni per la licenza
di DISTRIBUZIONE...!
In questo modo hai un prodotto, basato su Access come
interfaccia utente, codice Report ecc..., ma le tabelle
risiedono su un Server che non usa JET.
Per quanto riguarda ADO, se usi A>97 direi che non solo
è meglio, ma che usando la struttura ADP dedicata per
i progetti Nativi con SQL_SERVER ti sbarazzi dell'interfaccia
di JET(DAO), alla quale Access-JET non può rinunciare.
MSDE ti da la possibilità di svulippare all'interno del SERVER
procedure che se ben utilizzate rendono l'estrazione dati
estremamente veloce, anche nel caso di accessi contemporanei.
MSDE supporta max 5 utenti a velocità piena, poi le prestazioni
degradano in base al numero di UTENTI.
Rimane sempre molto meglio di ACCESS(JET).
Ciao.
@ALex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:a374cf14ee55725d41...@mygate.mailgate.org...

Come mai non sei tanto d'accordo a collegare la tabella pricipale con le
altre dieci??
in ogni modo, comincio a fare delle prove e poi vediamo
Ciao Napoleone

 Ciao Napoleone
Non è che non sono, ma non si capisce il motivo visto che
non hai fatto un'esempio un pò calzante.
Spiegata come l'hai spiegata, non è sbagliata l'idea, ma
sembra sbagliata nel tuo caso per come hai impostato
la cosa....!(Sempre considerazione affrettata).
Se passerai a MSDE non ti pentirai.
Ciao.
@Alex.

 ha scritto nel messaggio
news:c27qtt$bmo$1...@lacerta.tiscalinet.it...

Con MSDE, debbo partire da zero con un nuovo progetto,
oppure posso recuperare qualche cosa da un altro db
Grazie NApoleone

 Grazie NApoleone
Dipende da come l'hai sviluppato, se hai usato ADO direi
che puoi recuperare tutto, salvo il fatto che dovrai migliorarlo
sfruttando le SP e le View(Ex query).......!
Il metodo di gestione è differente, ma quando hai un Recordset
poi è come prima.
Ti consiglio vivamente di appogiarti a qualche buon Testo, sul SC
trovi un consiglio ottimo completo di Codice ISBN....!!!
@Alex.

Ti ringrazio, seguo il tuo consiglio ed in seguito,
se ci sarà un seguito, ti coinvolgerò.
Napoleone

 Napoleone
Se prenderai questa strada, e la consiglio vivamente,
noterai una sostanziale crescita del tuo prodotto.
In bocca al LUPO, buon lavoro.
Ciao.
@Alex.