Newsgroup: it.comp.lang.visual-basic
Titolo: Ottimizzazione database

Salve a tutti.
Sono un principiante (e dal tenore delle domande si puo' notare). Ho letto
che per ottimizzare un database occorre evitare ridondanza di campi. Quindi
se nel mio mdb ci sono 1 tabella (testata) e 1 tabella (corpo) + 37 tabelle
tutte collegate al corpo, e' il caso che nella tabella corpo vada a
registrare gli IDcodici delle singole piuttosto che, per esempio, le
descrizioni. Fin qui mi pare ok.
Ma mi chiedo : quando per esempio dovro' variare una scheda , leggendola mi
trovero' tutti codici numerici, quindi dovro' gestire doppi campi (magari
uno nascosto e l'altro no) in cui dovro' memorizzare gli IDcodici e gli
altri per visualizzare le descrizioni. Giusto ?
O c'e' un altro metodo ?
Grazie

"Carmelo R." <rgg...@NOSPAMyahoo.it> ha scritto nel messaggio
news:A%hec.59299$rM4.2...@news4.tin.it...

Non so se ho capito la domanda,
ma una relazione uno a molti, e lo puoi vedere costruendo una query o vista,
prevede per il campo uno la ripetizione del valore quanto sono i record per
il campo molti.
Penso conviene aiutarti costruendo query con Access o viste con Sql server.
Ave
giuseppeD

 altri per visualizzare le descrizioni. Giusto ?
Non credo di aver ben capito la domanda.
In linea di massima dovrebbe funzionare così:
1) Tabelle anagrafiche:
Codice (campo chiave univoca), Descrizione, proprietà varie del'item
2) Tabelle "real time"
Campi chiave univoca, campi codici anagrafiche, eventuale descrizione,
proprietà varie della riga
3) Tabelle "storiche"
Campi chiave univoca, codice + descrizione + proprietà varie
dell'anagrafiche, proprietà varie della riga.
Ti faccio un esempio per la 3:
Metti di avere la fattura per PincoPallino di pezzi 2 "xyz" per 100 euro
l'uno.
Totale 200 euro.
Benchè il prezzo sia memorizzato nella tabella Articoli, la fattura non puoi
gestirla come nel caso 2 (IDRiga, CodiceArticolo) e ricavarti il prezzo
della fattura dal prezzo dell'articolo, perchè se l'anno prossimo viene la
finanza e ti chiede una ristampa di quella fattura, e il tuo articolo adesso
costa 120 euro...
Puoi invece usare il caso due se ti si chiede di quantificare la giacenza a
magazzino per l'articolo xyz:
La tabella magazzino avrà CodiceArticolo e Qta, se ti serve sapere la
descrizione *attuale* dell'articolo basterà fare una join con l'anagrafica
sul codice.
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

 Penso conviene aiutarti costruendo query con Access o viste con Sql
server.
Ciao, cerco di spiegarmi meglio :
il mio mdb assomiglia molto ad una fattura con testata e corpo anche se non
lo e'. Ora tutti i campi inseriti nel corpo ( e sono 27 ) vengono prelevati
da altrettante tabelle che contengono (tra l'altro) ID e DESCRIZIONE e che
sono relazionate uno a molti con i campi presenti nel corpo. Quando
inserisco un valore, quindi, lo visualizzo in un dbcombo (che mi fa vedere
la DESCRZIONE) e ne memorizzo il codice nel corpo. Alla fine, quindi io
avro' qusta situazione "sicuramente" :
1 testata + 1 riga corpo che contiene 27 codici numerici (ID) oppure 1
testata + N righe corpo contenenti 27 x N campi ID.
Il mio problema e' quando dovro' modificare questo record.
Infatti quando lo leggero', mi ritrovero' una marea di ID che dovro'
riassociare alle DESCRIZIONI per poi modificarli nuovamente. Giusto ?
O c'e' qualcosa qualche passaggio logico che mi sfugge o che non ho compreso
bene ?
Grazie

[Carmelo R. = circa_...@NOSPAMyahoo.it in
A%hec.59299$
rM4.2...@news4.tin.it
] ha scritto:

Carmelo, non lo dico con cattiveria, ma ... non si capisce niente!
Ora ti racconto (no, non "ti spiego") come costruisco io le tabelle.
Immaginiamo quel (poco) che si può capire da quello che hai scritto:
dobbiamo gestire un archivio articoli e delle fatture. Bene, cerchiamo di
analizzare, prima grossolanamente e poi nei particolari.
Cosa contiene l'archivio articoli? Direi, semplicemente, tutto ciò che
riguarda gli articoli, null'altro. Quindi nulla che riguardi le fatture.
Esemplifichiamo (e semplifichiamo) in: codice articolo, descrizione, unità
di misura e prezzo corrente. Tutti gli articoli avranno la stessa struttura,
ma dati presumibilmente diversi. Un articolo è univocamente identificabile
da un codice, diverso, appunto, per ogni singolo articolo.
Cosa contiene una fattura? Direi, sempre semplicemente, una testata (dati
comuni a tutte le righe) e, appunto, una serie di righe. La testata potrebbe
prevedere il numero (univoco) della fattura, il cliente destinatario e le
modalità di pagamento. La riga (per tutte le righe della fattura) può
prevedere il codice (univoco dell'articolo), la quantità (secondo l'unità di
misura dell'articolo) e il prezzo unitario.
Ora, immaginiamo (sempre semplificando):
Campi Tabella ARTICOLI:
CODICE, testo 10 crt (chiave univoca di ricerca, vivamente consigliabile un
indice con chiave primaria e univoca)
DESCRIZIONE, testo 40 crt
UM, testo 2 crt
PREZZO, Currency
Campi Tabella TESTATE:
NUMERO_DOC, Long (chiave univoca di ricerca, vivamente consigliabile un
indice con chiave primaria e univoca)
CLIENTE_NOME, testo 40 crt
CLIENTE_INDIRIZZO, testo 40 crt
CLIENTE_CITTA, testo 20 crt
PAGAMENTO, testo 20 crt
Campi Tabella RIGHE:
CODICE_ARTICOLO, testo 10 crt
QUANTITA, Single
PREZZO, Currency
Bene.
Bene un tubo! Come facciamo a riconoscere/garantire l'appartenenza di una
riga (Tab.RIGHE) a una certa fattura fra tutte le possibili fatture presenti
(Tab.TESTATE)? Manca, evidentemente, qualcosa: un riferimento preciso a un
singolo record della Tab.TESTATE nella Tab.RIGHE. Quindi:
Campi Tabella RIGHE:
NUMERO_DOC_APP, Long
CODICE_ARTICOLO, testo 10 crt
QUANTITA, Single
PREZZO, Currency
Bene.
Bene un tubo! Come facciamo a riconoscere/garantire l'ordinamento delle
righe (così come l'operatore le ha inserite) di una fattura, per esempio in
stampa? Manca, evidentemente, qualcosa: un campo che mantenga l'ordinamento.
Questo potrebbe essere un Long autoincrementante del quale non c'importa il
valore, ma vogliamo che sia, appunto, sempre crescente. In tal modo, oltre
all'univocità, avremo anche un ordinamento (se esplicitato con una Order By
di un comando SQL) cronologico. Personalmente preferisco non usare gli
autoincrementanti e assegnare esplicitamente il numero di riga, ma ...
stiamo semplificando. Quindi:
Campi Tabella RIGHE:
NUMERO_DOC_APP, Long
ORDINE_RIGA, Long autoincrementante
CODICE_ARTICOLO, testo 10 crt
QUANTITA, Single
PREZZO, Currency
Parrebbe tutto a posto... no: ma manca un indice con chiave univoca (sempre
consigliabile, specialmente con ADO) alla Tab.RIGHE. Cosa può rendere
univocamente identificabile un record di tale tabella (non solo per
l'indice, ma anche solo per cercare, variare e riscrivere una specifica
riga)? Beh, ORDINE_RIGA, visto che è un autoincrementante e quindi non
ripetibile. Io preferisco (specialmente se ORDINE_RIGA viene assegnato dal
programma e non dal motore di gestione del database) prevedere
NUMERO_DOC_APP + ORDINE_RIGA. In questo modo un record della Tab.RIGHE è
univocamente identificabile anche se ORDINE_RIGA fosse assegnato a partire
da 1 per ogni nuova fattura...
Domande, alcune:
-Che succede se la descrizione dell'articolo cambia nel tempo e ci si vuole
comunque garantire la ristampa (identica all'originale) di una fattura anche
a distanza di tempo? Soluzione: ...
-Prima o poi occorrerà prevedere, oltre all'archivio articoli, anche
l'archivio clienti, non fosse altro (pur ipotizzando che non cambi mai, ...
cosa non vera nella realtà) per non dover riscrivere ogni volta nome,
indirizzo e città. Soluzione: ...

Grazie Lupo.
Sei stato estremamente esauriente, ma la mia problematica e' un po' diversa
da fatture/righe e ti spiego perche' :
quello che devo fare e' una scheda di rilevazione :
quindi avro' una (TESTATA) in cui inserisco i dati del soggetto intervistato
(il ns cliente/fattura) e poi delle righe (il ns corpo/fattura) in cui devo
inserire tutto il resto e le tabelle da cui attingere i dati da inserire nel
corpo (i ns ARTICOLI/fattura) che pero' qui sono tanti e tutti diversi.
Infatti la problematica prevede che io possa chiederti se ha un DIPLOMA o
una LAUREA, se hai frequentato CORSI SPECIFICI ecc.
Pensavo, quindi, quando dicevo "la mia problematica e' simile a fattura" di
gestire il tutto cosi' :
Esemplificando :
Campi tabella INTERVISTATI
CODICE , testo 10 crt (chiave univoca)
NOME, testo 20 crt
COGNOME, ECC
Campi tabella DIPLOMI
CODICE, testo 5 crt (chiave univoca)
DESCRIZIONE, testo 50 crt
Campi tabella LAUREA
CODICE, testo 5 crt (chiave univoca)
DESCRIZIONE, testo 50 crt
Campi tabella CORSI SPECIFICI
CODICE, testo 5 crt (chiave univoca)
DESCRIZIONE, testo 50 crt
Campi tabella TESTATA
NUMERO _DOC , LOng
CODICE CLIENTE (Da tabella INTERVISTATI)
..
..
..
Campi tabella RIGHE
NUMERO_DOC_APP (Long)
RIGA (Long autoincrementante)
CODICE DIPLOMA (da tabella diplomi)
CODICE LAUREA (da tabella laurea)
CODICE CORSI SPECIFICI (ta tabella).
ma, c'e' un ma .....
l'intervistato potrebbe avere 2 o piu' corsi specifici ....
quindi io ho pensato di strutturare la tabella cosi' :
Campi tabella CORSI SPECIFICI
CODICECORS, testo 5 crt (chiave univoca)
DESCRIZIONE, testo 50 crt
SUBCORSI (testo 1 crt)
+
tabella SUBCORSI
CODICESUB, testo 5 crt (chiave univoca)
DESCRIZIONESUB, testo 50 crt
CODICECORS, testo 5 crt
 e le ho collegate con una relazione 1 a molti tra loro tramite il campo
CODICECORS
Se SUBCORSI = S allora nel CORPO dovro' inserire "n" codici in piu' ...
schematicamente avro' :
TESTATA
intervistato : cod01
nome xx, cognome yy
nato il 01/01/2000
a yyyyy
CORPO
riga           coddiploma       codicelaurea       codicecorso
specializzazione
----------------------------------------------------------------------------
----
riga1              D01                   L01                 CORSO01
SPE03
riga2                                                               CORSO01
SPE09
riga3              D02
riga4                                       L02
in questo caso il sig. xx ha detto di avere 2 diplomi (D01, D02) 2 lauree
(L01, L02) e 2 corso di specializzazione aziendale privato (CORSO01) uno in
SPE03 (marketing) e uno in SPE09 (commerciale)
Tutto questo va memorizzato, suppongo, nella tabella  CORPO, ma non so
proprio come.
P.S. le tabelle SUB_xxx sono collegate alle tabelle principali tramite
relazione 1 a molti
le tabelle principali sono collegate a CORPO tramite relazioni 1 a molti.
E' errato fare cosi' ?
Scusa la mia lungaggine, ma spero di aver bene descritto la problematica.
Ciao.

 frequentato CORSI SPECIFICI ecc.
Considera i corsi, diploma e laurea compresi, come le righe della fattura.
Ogni intervistato avrà quindi tante righe abbinate allo stesso (a che serve
la tabella TESTATE?) quanti sono i corsi (normali o specifici) seguiti...


Ciao Carmelo,
da quello che mi sembra di capire devi creare un sistema per registrare il
risultato di alcuni questionari. A parte tutti i suggerimenti che ti hanno
gia' dato gli altri io ti consiglio di non creare troppe tabelle ma di
generalizzare il tutto (ci metterai piu' tempo a creare il programma ma poi
potrai utilizzarlo per un sacco di altre applicazioni e se il cliente ti
chiede di aggiungere una domanda al questionario lo fai in 5 secondi). Ti
faccio un esempio di quello che ho in mente e spero di essere
sufficientemente chiaro:
Crea la tabella TESTATA con la struttura che hai gia' detto (+tabella
INTERVISTATI collegata chiaramente)
CODICE, NOME, COGNOME
Tabella Righe - Io qui metterei pochissimi campi:
   IdRiga - long da utilizzare come chiave primaria
   Ordinamento - double da utilizzare per l'ordinamento delle righe come
giustamente ti ha consigliato Lupo
Tabella RigheDettaglio - questa tabella conterra' i valori delle varie
righe, in pratica in questo modo non sei obbligato a prevedere un preciso
numero di domande per riga ma potresti metterne di piu' o di meno di quello
che avevi previsto
   IdDettaglio - long da utilizzare come chiave primaria
   IdRiga - punta alla chiave primaria della tabella RIGHE
   IdTipoValore - Identifica il tipo di valore (la cui descrizione e' nella
tabella TipiValori)
   IdValore - Identifica il valore (la cui descrizione e' nella tabella
Valori)
Tabella TipiValori - questa tabella conterra' in pratica l'elenco delle
domande
   IdTipoValore - long da utilizzare come chiave primaria
   DescrizioneTipoValore - descrizione
   Ordinamento - se volessi scegliere l'ordine delle domande....
    Per esempio questa tabella potrebbe essere:
      1-Tipo diploma
      2-Tipo laurea
      3-Corso specifico
      4-Hobbies
      5-ecc. ecc.
Tabella Valori - questa tabella conterra' le alternative per ogni domanda:
   IdValore - long da utilizzare come chiave primaria
   IdTipoValore - Identifica il tipo di valore e punta alla tabella
TipiValori
   DescrizioneValore - descrizione
   Ordinamento - anche qui non farebbe male per semplificare la vita
all'utente....
    Per esempio questa tabella potrebbe essere:
     1 - 1 - Diploma 1
     2 - 2 - Diploma 2
     3 - 3 - Diploma 3
     4 - 2 - Laurea 1
     5 - 2 - Laurea 2
     6 - 2 - Laurea 3
     7 - 2 - Laurea 4
     8 - 3 - Corso specifico 1
     .......
Magari prova a costruirti le tabelle con Access e visualizza graficamente il
tutto cosi' forse sara' piu' chiaro.
Ripeto: in questo modo lo sviluppo richiedera' sicuramente qualche ora in
piu' ma in futuro vedrai che te ne fara' risparmiare parecchio.
Ciao


 bene ?
Conviene leggere la risposta di Lupo
Ragioniamo
Testata
IDOrdine|Data|IDCliente|IDSpedizioniere|TipoPagamento|AffidalilitàCliente|Pe
rcentualeSconto|ecc.
Le righe
IDOrdine|IDProdotto|QtàOrdinata|QtàConsegnata|IDPrecedenza|ecc.
Per il prodotto avrai una tabella con i campi:
IDProdotto|Descrizione|ecc.
La combo conterrà la descrizione visualizzata e IDProdotto come campo
nascosto.
Se cambi per un IDProdotto la descrizione, nella tabella, ricostruendo
l'ordine verrà visualizzato un record con una descrizione diversa rispetto
all'originale.
A meno chè, si decida di inserire nelle righe dell'ordine
IDOrdine|IDProdotto|DescrizioneProdotto|QtàOrdinata|QtàConsegnata|IDPreceden
za|ecc.
Questa diventa tutta un'altra gestione, poco relazionale.
Dipende dall'ambiente di lavoro.
Ave
giuseppeD

 giustamente ti ha consigliato Lupo
Questa dell'ordinamento proprio non la capisco.
Secondo me non serve a un tubo.
Una volta che hai
- Tipologia del titolo,
- Data di conseguimento,
- Descrizione
- Voto
Hai tutto ciò che ti serve per ordinare in modo logico i tuoi titoli.
Un ulteriore campo di ordinamento non serve a niente.
Inoltr non ha proprio senso che sia double.
Se proprio vuoi un ordinamento "personalizzato" ti basta un intero, che è
più compatto e più performante.


 Secondo me non serve a un tubo.
Hai ragione, in questo contesto.
Avevo introdotto il concetto di ordinamento quando ipotizzavo righe di una
fattura...

 fattura...
Ah, in questo caso sì, ma l'ID riga non è solo l'ordinamento, è anche la
chiave univoca.
Ciao

[Zanna = 
circa_z...@virgilio.it
 in
8Vvec.60876$
rM4.2...@news4.tin.it
] ha scritto:

Certo, volendo usare gli autoincrementanti, cosa che io cerco di evitare,
pur avendone qualcuno introdotto in un momento di follia (no, sto
esagerando, ma non mi piacciono), giusto per avere dei riferimenti univoci e
"brevi". In realtà la mia chiave univoca di una riga documento è fatta da 7
campi:
Tipo documento, origine, emesso/ricevuto, sezionale/bollettario, sigla,
numero e, finalmente, numero riga univoco nel documento.
Inoltre, per consentire lo spostamento (in su/giù) di righe nel documento
anche a posteriori, ho una campo riga_ordinamento (univoco nel documento,
inizialmente pari a numero riga, ma non compreso nella chiave) che uso per
l'Order By quando devo elencare le righe del documento.

 l'Order By quando devo elencare le righe del documento.
Ecco, questo campo ordinamento potrebbe benissimo essere sostituito dall'ID
riga, anche perchè non credo sia possibile stampare una fattura una volta
ordinata in un modo e una seconda volta in un modo diverso.
Inoltre non avrebbe senso avere un ordinamento differente dal numero di riga
stesso.


 di riga stesso.
Ehm... vedi sopra. Il numero univoco di riga viene assegnato quando la riga
nasce e costituisce chiave, l'ordinamento è "dinamico" e non tocca la chiave
perchè il numero di riga non cambia, solo il suo ordine nell'elenco.

 non si saprebbe mai qual è la seconda riga di una fattura.
Beh, la seconda riga è quella che, indipendentemente dal valore del suo
(eventuale ) ID autoincrementante, viene per seconda in un Order By ID_riga.
No?!

 deve poterlo fare...
Sě, certo.
L'utente puň cambiare l'ID riga, inserirne una nuova, toglierne una...
L'ID riga rimane comunque univoca e identifica anche l'ordine delle righe.
Forse stiamo parlando della stessa cosa, ma per me per identificare una riga
basta sapere
1) l'Id (il numero) della riga
2) L'id del documento a cui appartiene.


 Non capisco il perchè.
L'ho già detto:
Perchè possono esistere "n" bolle numero 10, se distingui e combini fra
emesse/ricevute e bollettario.
Io poi, per necessità mie e/o dell'utenza, ho introdotto altri due campi di
differenziazione, magazzino origine e sigla.
Che poi tu voglia intendere "emulo/raggruppo/identifico quei 6 campi con un
mio codicillo che funga da ID univoco del documento", ok, posso comprendere.

 mio codicillo che funga da ID univoco del documento", ok, posso
comprendere.
Questi accrocchi è meglio lasciarli perdere :)


 Questi accrocchi è meglio lasciarli perdere :)
Ce ne andremo mai fuori da questo quiz?
Immagina di avere:
bolla numero 10, ricevuta (senza bollettario, non gestito)
bolla numero 10, emessa sul bollettario A
bolla numero 10, emessa sul bollettario B
e anche:
fattura numero 10, ricevuta (senza sezionale, non gestito)
fattura numero 10, emessa sul sezionale IVA 1
fattura numero 10, emessa sul sezionale IVA 2
Qual è per te la chiave di individuazione del documento?

 numero doc è il numero gestional-fiscale del documento.
E' vero, hai ragione :)
Adesso infatti mi ricordo il perchè oltre a numero doc ho messo anche un id
doc che mi gestisco io e che è chiave primaria nella testata, e campo di
join nelle righe


Grazie a tutti.
Consigli preziosi.
Provero' la soluzione proposta da Mino Fabio. In effetti quello che devo
fare io e' proprio la gestione di questionari. (.... l'avessi detto prima
saremmo arrivati al punto. Ma l'approccio che avevo affrontato era
sicuramente fuorviante ed errato).
Grazie di nuovo e alle prossime domande (che vi assicuro ci saranno !!)
Carmelo.