Newsgroup: it.comp.lang.visual-basic
Titolo: [BS] Su tabelle e struttura database (luuuungo)

Bene, di database "grossi" non me ne sono mai occupato e, seppur abbia
gia' comprato un bel libretto di 850 pagine su Database Design, come
al solito non ho tempo di leggerlo tutto prima di cominciare a
lavorare.
Quindi vi espongo cosa devo fare e vorrei che mi deste il vostro
parere spassionato su come gestireste la cosa.
Premetto che tutte queste cose ora in ufficio le fanno usando Word e
una serie spropositata di modelli di documenti e macro
spropositatamente grosse che preparai un po' di anni fa --si parla del
95/96--. Siccome Word e' andato bene finche' i documenti erano
relativamente pochi ma ora comincia ad andarci un po' stretto --anche
considerando le limitate possibilita' di ricerca all'interno dei
documenti vecchi che ci sono--, allora ho cominciato a lavorare a
qualche applicatido ad hoc che facesse le varie cose che mi servono e
alla fine la mia applicazione, che era nata come qualche programmetto
che faceva piccole cose, molto focalizzate, e' diventata con
un'applicazione con pretese sempre maggiori e alla fine si sta
evolvendo e sta diventando qualcosa di abbastanza "globale", dove ogni
programmetto ora non e' piu' tanto "etto" --bensi' piu' "one"-- e ha
bisogno di interagire coi dati anche degli altri.
Lasciando stare cosa utilizzero' come base dati --che tanto e'
accessibile via ODBC con qualche bravo ADODC--, ho bisogno di qualche
consiglio su come strutturare le tabelle. Al solito, le prestazioni mi
interessano relativamente poco e preferisco che la cosa sia facilmente
gestibile, eventualmente con dati replicati se questo mi permette di
capire e seguire meglio tutto il filo delle informazioni. Vi indico
brevemente cosa fa ogni singolo pezzo dell'applicazione e poi mi dite
che ne pensate. Spero di non portarvi via troppo tempo: al limite,
offriro' una Guinness a chi vorra' perdere tempo per me :)
1. Abbiamo un compilatore di tabelle per libretti uso e manutenzione.
Per tabella, intendo una tabella tipo quella che si fa in Word, cioe'
un testo "statico" che creo una riga alla volta e che poi stampo. Alla
fine della creazione, salvo questa tabella in una tabella di un
database. Per fare meno casino, chiamo tabella quella di testo e table
quella del db. Le voci delle tabelle, che in qualche modo poi mi
arrangio a stampare, sono le tradizionali da libretto
manutenzione/ricambi: codice, quantita', posizione e descrizione, dove
la posizione e' un numero progressivo --alfanumerico-- indicato nel
disegno che accompagna la tabella, utile nell'ordine dei ricambi per
dare un riferimento in piu'. Considerando che:
- nel database metto solo codice e descrizione
- avro' almeno 6 lingue --che diventeranno presto 9 o 10--
- il codice e' lo stesso in tutte le lingue
ho 2 alternative, ovvero:
- creo una sola table con un campo codice e tanti campi descrizione,
uno per ogni lingua
- creo una table per ogni lingua, con un campo codice e un solo campo
descrizione.
Io sarei piu' per la seconda.
2. Le descrizioni di cui ho parlato prima sono prelevate,
all'installazione del sistema, dal programma gestionale e sono quelle
che utilizziamo negli ordini ai fornitori e nell'uso interno per altre
scartoffie fiscali. Nei libretti uso e manutenzione e' comodo, spesso,
utilizzare descrizioni differenti da quelle del sistema gestionale,
quindi devo avere a disposizione un secondo archivio
codice+descrizione, che contenga le descrizioni modificate. Ad
esempio, quando ordino un cuscinetto, indico il codice del fornitore e
la misura --tipo SKF 35x50x12ZZ--, mentre nel libretto uso e
manutenzione e' piu' utile indicare il tipo UNI del cuscinetto,
perche' cosi' uno poi si compra quello che gli pare --e gli scade la
garanzia, ma tant'e'...--, quindi scrivo "cuscinetto UNI 7035/51".
Quindi, considerando che:
- se una descrizione viene modificata, quella originale *non dovra'*
mai piu' essere utilizzata
- se una descrizione viene modificata, quella nuova verra' *sempre*
utilizzata e non saranno possibili ulteriori modifiche e non e'
possibile avere 2 modifiche diverse sulla stessa descrizione
- non voglio perdere la descrizione originale, per una serie di
considerazioni che ora non faccio
- quando il mio applicativo deve cercare una descrizione nella base
dati, prima controlla se ne esiste una modificata e, se esiste, usa
quella, poi, se non esiste, usa quella "originale".
ho 2 alternative:
- aggiungo una colonna alle table del punto 1.
- creo altrettante table e ci metto dentro solo le descrizioni
modificate
Io sarei piu' per la prima possibilita'.
3. devo rivedere gli ordini a fornitori. Nel database ho gia'
preparato una table che contiene tutti i dati necessari a spedire un
ordine e i fornitori sono caratterizzati da un numero progressivo
unico. Quando faccio un ordine
- scelgo il fornitore
- assegno automaticamente un numero progressivo all'ordine
- richiamo, per codice, uno alla volta i pezzi da ordinare e specifico
la quantita' di ognuno
- stampo l'ordine e lo spedisco via fax
Ecco, il consiglio che vi chiedo qui e' come salvare gli ordini gia'
fatti. Siccome ogni ordine ha un numero di righe diverso ma ogni riga
ha lo stesso numero di campi, ho pensato a 1 sola table dove salvo
tutti gli ordini e metto:
- un campo per il numero dell'ordine
- un campo per il codice del pezzo
- un campo per la quantita'
- un campo per la descrizione
- un campo per eventuali note
e poi creo una seconda table dove metto
- un campo per il numero dell'ordine
- un campo per il numero identificativo del fornitore
L'alternativa sarebbe aggiungere il campo identificativo del fornitore
nella prima tabella, ma lo ripeterei davvero tante volte inutilmente
e, forse, mi e' piu' chiaro se li tengo separati.
Io sarei, quindi, per la prima soluzione --2 tables--: c'e' qualche
motivo per cui dovrei scegliere la seconda, secondo voi?
4. ho un programma che crea le cosiddette schede macchina. Per noi,
una scheda macchina e' un foglio descrittivo delle parti che
compongono una macchina che viene passato agli operai in officina nel
momento in cui parte la produzione di una macchina. Ogni scheda
macchina e' distinta da un codice progressivo ed unico --che sara' poi
la matricola della macchina finita-- ed e' composta di 9 sezioni,
ognuna delle quali rappresenta una parte della macchina: impianto
elettronico, impianto idraulico, carrozzeria, gruppo trazione, ecc. A
seconda delle macchine, il numero di linee di ogni sezione e'
variabile, pero', come prima, ogni linea ha sempre lo stesso numero di
campi. Quindi pensavo di creare una sola table dove metto tutte le
linee di tutte le sezioni di tutte le schede macchina, includendo un
campo "matricola" che discrimina le righe di una certa scheda macchina
e un campo "sezione" che discrimina a quale sezione questo campo
appartiene. A dire la verita', in fondo ad ogni scheda ci sono un
numero variabile di note --praticamente, linee di tipo stringa--, ma
questo problema e' facilmente risolvibile creando una seconda table
con un campo "matricola", un campo "progressivo" per tenere in ordine
le note e un campo "nota" che contiene la nota vera e propria. Data la
variabilita' delle parti che compongono una sezione, non mi vengono in
mente alternative a questa: avete consigli alternativi?
5. Problema analogo al precedente e' quello del salvataggio dei
libretti uso e manutenzione all'interno del database: ho un numero
variabile di sezioni, ogni sezione, pero', e' composta da un --lungo--
testo, da una tabella, le cui linee sono composte sempre da 4 campi e
da un disegno. Naturalmente, come nei casi che ho gia' indicato,
salvarei tutte le tabelle insieme, aggiungendo un campo
"codice_tabella" che mi consente di capire quando comincia una tabella
e quando finisce.
Ora, capisco che sembri --e sia-- un lavoraccio, ma siccome non me lo
fa nessuno neanche a pagarlo devo farlo io e siccome di db non me ne
intendo proprio per niente, devo appoggiarmi a voi. Anche perche' le
software house della zona, che non mi fanno il lavoro, non mi fanno
neanche la consulenza --non ho capito il motivo--, comunque tant'e'...
In tutti i casi, anche facendoci i conti, il db viene con una
struttura --penso-- non troppo complessa e comunque non molto
ingombrante.
Nelle table codici+descrizioni del punto 1. e 2. ci saranno si' e no
15.000 linee --x 7 lingue--.
Nelle table per gli ordini a fornitori, penso che con 3 o 4.000 righe
all'anno io ci stia dentro piu' che abbondantemente --saranno molte
meno, ma mi tengo abbondante per una stima pessimistica-- e anche qui
i campi sono pochi.
Nelle tabelle delle schede macchina, avro' una 50/60 linee per ogni
scheda macchina. Le schede macchina della nostra storia sono 13.500,
ma ci finiranno dentro solo quelle fatte da ora in poi, salvo voler
provare di recuperare quelle piu' recenti ancora dentro al gestionale
--che, pero', sono salvate come semplice foglio di testo e quindi
inutilizzabili per fare alcun tipo di ricerca. E' da qui che e' nata
la necessita' di creare un programma ex novo basato su database--.
anche se mettessi dentro le ultime 5.000, farebbero, diciamo, 250.000
record di 4 campi stringa e 2 numerici, cioe' un'inezia.
Nelle tabelle dei libretti uso e manutenzione la cosa e' un po' piu'
pesante perche' abbiamo una media di 40 linee a tabella, per una media
di 10/12 tabelle a libretto, per 6 lingue, per 80 modelli di macchine
diverse. Che farebbero la modica cifra di altri 200.000 record o piu',
solo che poi tante tabelle sono usate in vari libretti e quindi
restano di meno.
Alla fine delle fini, il database non viene particolarmente grosso,
solo che bisogna decidere bene e prima come strutturarlo perche' a
cambiarlo dopo e' un dramma.
Altra cosa: consideriamo uno che lavori cambiando con una certa
frequenza le table a cui accede. Se non ho capito male, bisogna creare
un recordset diverso ogni volta: e' una cosa che richiede molto tempo
--supponendo latenza della rete pari a 0, che e' abbastanza vero nel
mio caso--?
Prometto di leggermi bene come funzionano i recordset su MSDN, ma se
avete qualcosa di particolare da segnalarmi, tutto e' bene accetto.
Per ora penso di avervi portato via fin troppo tempo e, nell'attesa di
pagare un camion di Guinness, vi ringrazio in anticipo e vi saluto :)
-- 
      Gianni "bugbarbeq" Rondinini, 25, RA, 242, 152
  VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!
 Opel/ECC Calibrezio EVO-IV --- Kawasaki "Gas Gas" ZZ-R 1100
 ICQ# 36893168 - IRCNet: bugbarbeq, @ on #linux-it & #NetBSD


P.S. Si può avere una Ceres, la birra scura non mi piace.
Ciao
Alfonso Moscato

mio caso--?
????????? eh ????
Salve
            Dbg

Hai bisogna di una nuova lingua? aggiungi un record.
Visto che grossomodo mi proponi la stessa cosa che mi propone Alfonso,
andiamo avanti direttamente di la' :)
Saluti e grazie ancora.


P.S. Si può avere una Ceres, la birra scura non mi piace.
Anche 2 :)


 enormemente piu' veloce del precedente 6.5.
Lascia stare Sql server 6.5; va ma 7.0 č tutta un'altra cosa.
MySql č ottimo.
PostgreSQL non lo conosco e non so che dirti...
Ciao
Alfonso Moscato

PostgreSQL non lo conosco e non so che dirti...
PostgreSQL ha tutte le features di MySQL piu' alcune altre cose --ma
io non mi ricordo le differenze--. Lo scelsi per problemi di licenza
di MySQL, che non e' sempre stato GPL'ed e da allora vado avanti con
l'idea di usare quello. So che MySQL e' leggermente piu' limitato, ma
guardero' un po' cosa effettivamente fanno prima di prendere una
decisione, anche se oramai ci sono sotto e devo muovermi.
Saluti e grazie.


 versione prendere.
Solo una precisazione.
Se usi due table per le descrizioni, allora eliminala completamente dalla
table 1, altrimenti ogni volta che te ne serve una, devi
aprire la table 1
Vedere se la descrizione č obsoleta
se sě aprire la table 2 e cercare la descrizione.
Invece se tieni tutte le descrizioni nella table 2 devi aprire solo quella e
buonanotte.
Ciao
Alfonso Moscato