Newsgroup: it.comp.appl.access
Titolo: efficenza mdb in rete

Secondo voi per aumentare la velocita e l'efficenza del BE in rete sarebbe 
opportuno utilizzare una sola tabella che contenga, per esempio, tutti i 
tipi di documenti (ordini,fatture,bolle,preventivi,ecc...) che si 
differenziano tramite il campo tipoDocumento (ovviamente indicizzando 
tipodocumento) o sarebbe meglio utilizzare una tabella per ciascun tipo di 
documento!
grazie 

 ha scritto nel messaggio news:QN3pg.21488$zy5.4...@twister1.libero.it...

Nei parametri per migliorare i tempi di risposta io ci inserirei anche l'HW...
Ciao.
-- 
Sergio MAZZA 


Credo che ti convenga la prima ma non tanto per la mole di dati che
viaggiano in rete, ma per la possibilità di tenere tutto sotto controllo in
una sola tabella
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 grazie
8-)
-- 
Ciao
Pablitomf (Maurizio Facciuti)
Access : Ver.97 - 2K
----------------------------
http://www.accessgroup.it/
----------------------------
Non mi fido molto delle statistiche, perchč un uomo con la testa nel forno
acceso e i piedi nel congelatore statisticamente ha una temperatura media.
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Secondo voi per aumentare la velocita e l'efficenza del BE in rete sarebbe

Tendenzialmente concordo con tutti i suggerimenti che già ti hanno
dato, ma non è il caso
di dimenticare la razionalizzazione delle informazioni e la
Normalizzazione delle Tabelle.
Possibile che Ordini, Fatture, Bolle e Preventivi abbiano tutti la
stessa esigenza di archiviazione...??
Io non credo e vedo una difficoltà iniziale non trascurabile in questo
es:
Prendiamo in considerazione la ChiavePrimaria della tabella, cosa metti
un Counter
oppure un Codice, mettendo tutto in una tabella sei obbligato a mettere
un Counter
perchè il codice Documento sarebbe da gestire a seconda del
DocumentType....!
La Fattura prevede una numerazione progressiva in un certo modo,
l'ordine sicuramente
in un'altro e per non parlare delle Bolle, infine i preventivi sono un
documento che non serve
finchè non viene tramutato in Ordine....!
Quindi avresti 2 campi indicizzati che in realtà sarebbero 2
PrimaryKey, senza contare che
in qualsiasi modo se chiedi di vedere un Preventivo ti devi recuperare
sia Bolle, Ordini e fatture...., e con Access queste cose si pagano...!
Data la possibile differenziazione delle tabelle io valuterei bene
questa scelta che potrebbe essere meno banale di quanto si pensa.
@Alex

stessa esigenza di archiviazione...??
Fondamentalmente sě: considera che normalmente preventivi e Ordini verranno
trasformati in DTT o Fatture.
La struttura degli archivi č praticamente identica.
La maggioranza dei gestionali in commercio archivia le informazioni in
tabelle di testate e righe comuni a tutte le tipologie di Documento.
Le numerazioni separate vengono gestite semplicemente memorizzando i
progressivi in altra tabella (legata alla causali Documento in genere).
D'altra parte dato che in quasi tutti i gestionali č consentita la creazione
di Causali Documento assai personalizzate, non sarebbe possibile stabilire a
priori degli archivi "dedicati" in cui memorizzare Documenti la cui natura
puň essere stabilita successivamente dall'utente.
In quanto alla chiave primaria, non cambia nulla: Counter in entrambe le
ipotesi (o chiave multicampo univoca, che contenga Data/Ora ad ex.)
Ciao, Simone

 Ciao, Simone
Ammetto la mia completa inesperienza in Gestionali, ma pensavo che
almeno i preventivi
fosse opportuno lasciarli in una Tabella separata ed accodarli solo in
caso di trasformazione.
In ogni caso come l'hai spiegata tu, e sicuramente come anche la
intendevano gli altri
ha un senso decisamente ovvio, il problema all'origine è Access come
BE che mi metteva
un dubbio su questa struttura.
Su un DB_Server il tuo discorso sarebbe indubbiamente normale, ma in
una situazione
con BE(Access) e pensando all'ottimizzazione delle prestazioni potrebbe
sempre valere..?
Personalmente non ho mai sviluppato un gestionale, ma quando usavo
Access come BE
mi ero accorto che le prestazioni avevano variazioni decisamente
rilevanti usando l'approccio che hai esposto, che peraltro trovo
sicuramente corretto.
Magari ricordo male.....
Ciao
@Alex

"Alessandro Baraldi" >
Ammetto la mia completa inesperienza in Gestionali, ma pensavo che
almeno i preventivi
fosse opportuno lasciarli in una Tabella separata ed accodarli solo in
caso di trasformazione.
Beh, non c'è motivo in fin dei conti di trattare i preventivi diversamente
dagli Ordini o altre tipologie di documento.
Su un DB_Server il tuo discorso sarebbe indubbiamente normale, ma in
una situazione
con BE(Access) e pensando all'ottimizzazione delle prestazioni potrebbe
sempre valere..?
Personalmente non ho mai sviluppato un gestionale, ma quando usavo
Access come BE
mi ero accorto che le prestazioni avevano variazioni decisamente
rilevanti usando l'approccio che hai esposto, che peraltro trovo
sicuramente corretto.
Magari ricordo male.....
Boh:  non vedo uno scenario specifico in cui le prestazioni possano
degradare significativamente ... parliamone.
Ciao, Simone

 Ciao, Simone
@Alex

"
Purtroppo ora stò andando a memoria, e sinceramente è la cosa che
meno
mi funziona, anzi...non và proprio !
Ma parliamone giusto per parlarne....
In ogni caso, parlo sempre per JET, discorso che non farei mai per
altri DB_Server.
Ipotizzo 1 sola tabella con circa 100.000 Records tra Ordini, Bole,
preventivi
ecc...!
In qualsiasi modo, anche indicizzando il traffico in rete sarebbe di
100.000 indici
andando a lavorare in Multiutenza, il peso di estrazione dati potrebbe
essere rilevante.
Dividendo, per ottimizzazione, le Tabelle verrebbe da se che il numero
di Indici
scambiati Client-Server sarebbero ridotti.
Sì e no: in fin dei conti si tratta solo di "spostare in là il problema":
anche dividendo gli archivi a seconda della tipologia di Documento, prima o
poi l'archivio Bolle raggiungerà determinati volumi.
In realtà "più prima che poi" dato che gli Ordini verranno via via evasi in
DDT...
Ciao, Simone

 Ciao, Simone
Ciao
@Alex

 ha scritto nel messaggio 
news:1151688539....@y41g2000cwy.googlegroups.com...


 non ricorrere spesso alla UNION SELECT?
Rispondi dopo il quoting cortesemente..!
Quanto dici ora è decisamente corretto, anche se in ogni caso il
calcolo OnTheFly
come mi pare di capire tu voglia fare è praticamente assurdo con
Access, quando avrai
qualche centiaio di migliaio di movimenti di materiale Access si
pianterà di certo.
Usando Access come BE dovrai curarti di tenere aggiornate le giacenze
Runtime
memorizzando lo Stock di magazzino e facendo molta attenzione a gestire
questo
per evitare un disallineamento.
Credo che anche con un server SQL il calcolo OnTheFly sia come darsi
martellate
sulle dita perchè personalmente lo ritengo fallimentare in partenza
dal punto di vista prestazioni.
Ricorda che a tabelle vuote è sempre facile far funzionare le cose, ma
tabelle piene
sono dolori...
@Alex