Newsgroup: it.comp.appl.access
Titolo: Base di Dati: meglio tante tabelline o una sola tabellona

Buongiorno a tutti.
Uso Access 2003.
Da tempo sviluppo una applicazione che � nata con tante tabelle:
   - BOLLE
   - FATTURE
   - FATTURE FORNITORI
   - ORDINI
   - OFFERTE
e tante sotto-tabelle:
   - RIGHI BOLLE
   - RIGHI FATTURE
   - RIGHI ORDINI
   - RIGHI OFFERTE
Ora mi sono messo in testa di passare a due sole tabelle:
   - DOCUMENTI
   - RIGHI DOCUMENTI
Naturalmente nella tabella DOCUMENTI ci sar� un campo TipoDocumento che far� 
da discriminante.
Ho scritto una routine che fa tutti i passaggi del caso.
Mi accorgo per� che il BE con le tabelle � molto pi� ingombrante (Mb) nel 
caso delle 2 tabellone piuttosto che nel caso dell'altro con 9 tabelline 
iniziali. Questo perch� ci sono molti campi non comuni a tutti i tipi di 
documento che quindi rimangono vuoti. Un po' di domande:
1) � corretto questo modo di operare? Forse � pi� corretto mantenere 
separate le varie tabelle?
2) i campi che lascio vuoti (Null) dovrebbero NON occupare spazio su disco 
vero?
3) utilizzando il db in rete posso avere un decremento delle prestazioni 
dato che all'apertura di ogni maschera dovr� filtrare i dati?
Grazie.
Ciao
Silvio

 Silvio
Ciao Sivio
anch'io mi sono spesso posto il problema.
Comunque ho sempre optato per le tabelle specifiche.
Nei pacchetti standard ho visto ambedue le soluzioni.
Non mi pare che la soluzione "tabellone" dia vantaggi, c'è uno spreco
di campi e, oltretutto, occorre una doppia numerazione
(identificazione), una come documento ed una come protocollo (n.
fattura, n. ddt, ecc.).
Oltretutto non è assolutamente detto che ad un Ddt corrisponda una
fattura e che ambedue corrispondano ad un preventivo.
Quindi...
Vediamo se altri amici motivano differentemente.
Ciao
ALberto


Senza voler fare scuola a nessuno, non � mia intenzione.
Ma esiste la normalizzazione di dati  (un link 
http://support.microsoft.com/kb/209534/it
, ma trovi tonnellate in internet) 
fondamentale per la consistenza dei dati e non solo.
Quando non applicata... bh� � sempre un casino nei dati.
Poi ci sono le eccezioni.
Esempio: Ho cambiato residenza 4 volte e le comunicazioni della STESSA banca 
arrivano a tutti e quattro indirizzi diversi, lo so per certo.
Questo � un esempio di tabelle non normalizzate.
Nel tuo esempio della tabellona penso sia molto pi� faticoso non 
normalizzare per tenere i dati consistenti.
Il problema delle prestazioni � l'ultimo.
Prima i dati... poi il tuning ;-)
Ciao
Daniele 


Diciamo che l'accesso ai dati in un db relazionale DEVE essere
relazionale.....ogni entit� una tabella (questa � la teoria...). Pensa
accedere ad un preventivo su (in caso multianno per esempio) 10.000: il motore
ci mette un certo tempo. Se questi 10.000 sono nella stessa tabella tra 15.000
righe di fattura, 25.000 righe di bolle, 8.000 ordini ecc ecc ecc a cui
chiaramente relazioni anche un tot di altre tabelle (anagrafiche) secondo me
jet (o chiunque altro) fa la lingua + lunga.......Anche se qua ho parlato di
poche migliaia di record e la differenza non si vedrebbe, a lungo andare �
meglio spezzare. 
Comunque tieni a mente anche i prolungamenti orizzontali delle tabelle (Celko
docet!!!!!) per quei campi che non vengono valorizzati in tutte le righe ma
solo in casi sporadici.....
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it


Personalmente, quando possibile, sono propenso alla soluzione monotabella
La logica e' questa: stiamo parlando di documenti che strutturalmente si
somigliano moltissimo, hanno tutti una testata con dei dati del cliente,
fornitore, committente, ed un corpo con degli articoli che si ripetono
Che il documento sia un ddt, fattura, preventivo, offerta, acquisto, non
cambia niente, la struttura e' quella
Cambia molto nella semplificazione che tale impostazione permette durante la
creazione di nuovi documenti
Ad esempio per creare una fattura partendo da piu' ddt, se hai la stessa
struttura di testata e di corpo, si tratta di ciclare tra dei record
creandone altri di tipo diverso, e' un'operazione banale che non richiede
conversioni di nessun tipo se non dal tipo documento sorgente a quello di
destinazione
In sostanza puoi realizzare un sistema che crea un qualsiasi tipo di
documento partendo da uno o piu' documenti di qualsiasi altro tipo
E questa cosa e' estremamente utile quando fai un'offerta ad un cliente, lui
ti restituisce la confrma magari tagliando via una riga dal corpo, tu puoi
inviare a tua volta la conferma d'ordine semplicemente esportando l'offerta
in una conferma ordine ed eliminando la riga indesiderata, ovviamente il 
documento destinazione e' bene che si 'trascini' tutte le informazioni del 
documento di partenza
Io di solito aggiungo nel corpo una riga descrittiva del tipo "Da Documento 
PREVENTIVO A CLIENTE n.345 del 10/09/2003" e poi giu' tutti gli articoli
Quando devi fornire i materiali/servizi, dalla tua conferma d'ordine a
cliente puoi creare il ddt, e poi la fattura
Altra semplificazione e' nel creare dei report/resoconti, puoi dirottare
sulla stessa stampa tipi diversi di documenti, semplicemente indicando il
tipo documento desiderato
Per quanto riguarda le prestazioni non vedo proprio la differenza tra avere
una tabella da 10.000 record ed averne una da 50.000
Col cronometro alla mano, sono la stessa cosa, ovviamente se operi con
sistemi moderni (spero che non usiate ancora dei 286) e con
ricerche/collegamenti basandoti su campi con indice
Riassumento, per le ragioni sopra, io preferisco l'ipotesi Documentitestate
+ Documentirighe al posto delle varie tabelle ognuna per tipo documento
Ciao
RobertoA



Grazie RobertoA!
Mi conforta sapere di non aver preso una colossale cantonata: � da molto che
lavoro alla "conversone" ed ora mi stavano venendo forti dubbi.
Per quanto mi riguarda la soluzione pluritabellare sta diventando un po'
laboriosa a causa delle molte query UNION che mi tocca applicare per creare
vari report e maschere.
Io collego i vari documenti in modi diversi: le righe di DDT, FATTURE,
ORDINI, PREVENTIVI sono collegate tra loro da un IDCommessa (la tabella
COMMESSE sta sopra a tutte e non entrer� nella DOCUMENTI). Inoltre i DDT 
sono collegati alle FATTURE da un campo IDFattura (soluzione che si pu� 
ricreare nel caso della tabellona DOCUMENTI).
Per quanto riguarda le prestazioni non � tanto la velocit� dei singoli PC ma 
la gestione in rete che mi preoccupa.
Ancora grazie. Vedr� cosa fare.
Ciao
Silvio 

 Ma esiste la normalizzazione di dati  (un
CUT
non è questione di voler far sQuola, è la regola...
se qualcuno mi chiede come organizzare i dati, l'UNICA maniera
possibile è quella della normalizzazione (con relativa de-
normalizzazione finale). Il resto è fantasia e chiacchiere.
Esiste un metodo razionale e logico di organizzazione dei dati e deve
essere utilizzato.
Se poi vogliamo fare come ci pare, allora non ci preocupiamio di
scrivere in un NG...
Ciao
Red Wolf

Vediamo se altri amici motivano differentemente.
Ciao ALberto.
Non so, la soluzione della TABELLONA mi sembra sia sempre riconducibile alla
TABELLINE con delle semplici query. Ad esempio, pensavo di creare delle
query BOLLE, FATTURE, etc... e lasciarle nell'mdb in modo da avere sempre le
tabelline sott'occhio...
Per quanto riguarda lo spreco di campi, io pensavo che se lasciati Null non
occupassero spazio ma evidentemente mi sbagliavo.
Non capisco il problema della doppia numerazione: gi� adesso ho un IDFattura
(campo contatore) e un campo NumeroFattura.
I DDT li collego alle FATTURE tramite un campo IDFattura (sul DDT). 
Soluzione che si pu� applicare anche alla tabellona.
Vedr� il da farsi.
Grazie.
Ciao
Silvio

>

S�, i valori sono pi� o meno quelli: tabella DOCUMENTI 40.000 record, 
tabella RIGHE 130.000. In effetti non si vede nessun decremente delle 
prestazioni ma temo che in rete la cosa diventi pesantuccia. Con il passare 
degli anni poi...
Non so cosa sostenesse Celko e quali problemi possano dare i prolungamenti 
orizzontali delle tabelle. Francamente al momento, oltre all'aumento della 
dimensione del BE e un po' di perdita di "semplicit�", non ne vedo altri ma 
scrivo qui proprio per capire...
Grazie mille.
Ciao
Silvio 

 Prima i dati... poi il tuning ;-)
Ciao Daniele.
Grazie per la risposta.
Prima di aprire questo thread ho letto parecchio sulla normalizzazione dei
database. Il problema � proprio capire se i vari documenti DDT, FATTURE,
ORDINI etc. siano dati "coerenti". Secondo me *S�* visto che sono documenti
molto simili (data, numero, IDindirizzo, Intestazione, etc etc). Anche i
righi mi sembrano molto coerenti (Unit�Misura, Quantit�, Descrizione,
Prezzo, Sconto, Importo etc etc).
La normalizzazione condanna senza appello ogni tipo di ridondanza dei dati
ma nel mio caso non c'� alcuna ridondanza. C'� sicuramente un "prolungamento 
orizzontale delle tabelle" (come dice Fair87) ma non ho ancora capito se � 
da evitare o meno...
Scusa ma non ho capito se con la tua frase "Nel tuo esempio della tabellona 
penso sia molto pi� faticoso non
normalizzare per tenere i dati consistenti" mi consigli o meno la filosofia 
della tabellona...
Grazie mille.
Ciao
Silvio

scrivere in un NG...
Ciao Red Wolf.
Quindi come devo interpretare le regole della normalizzazione? Si va verso 
una migliore normalizzazione nel caso della tebellona o nel caso delle 
tabelline?
Grazie.
Ciao
Silvio

>  http :// support.microsoft,com /kb/209534/it, ma trovi tonnellate in


Mi sono spiegato male. Una possibile soluzione quando ti servono campi in + ma
non per tutti i record � quella di una relazione 1-1 tra 2 tabelle, dove metti
nella tabella 1 tutti i campi 'sempre usati' e nella tab 2 quelli meno
frequenti e leghi con l'id. Chiaro che qua per� si parla di normalizzazione,
che mi sembra l'opposto di quello che vuoi fare tu.......Io posso solo darti
la mia idea a riguardo, che � quella di entit�=tabella. A volte la questione
dei join per la 'denormalizzazione' pu� essere pesante ma alla lunga c'� solo
da guadagnarci con una buona struttura relazionale.....Attenersi a tutte le
forma normali � 'umanamente' impossibile ma provarci.....


 forma normali � 'umanamente' impossibile ma provarci.....
OK, potrebbe essere un'idea quella delle tabelle collegate 1-1 ma secondo me 
complica ulteriormente l'architettura del db.
A mio modo di vedere, la gestione dei documenti con un'unica tabella non 
viola le regole di normalizzazione (ma naturalmente potrei sbagliarmi).
Grazie.
Ciao
Silvio

Silvio ha scritto:


In effetti...un po' come tenere carichi e scarichi di magazzino in un unica
tabella (entit� MOVIMENTI) o in 2 tabelle (entit� CARICHI e SCARICHI)......Se
generalizzi troppo per� arrivi alla denormalizzazione completa......Ma queste
sono solo opinioni personali!!!!!


 Silvio
tabelline, in linea di massima
con una sana denormalizzazione finale...
-- 
--
Grazie
Ciao
Red Wolf
-- -- --