Newsgroup: it.comp.lang.visual-basic
Titolo: Consiglio struttura DB

Premetto che avevo inviato il post anche sul NG dei DataBase ma senza
risposte, quindi provo a chiedere qui ^__^.
Ciao a tutti,
tra un po' mi troverò a fare la revisione di un'applicazione che gestisce
degli articoli.
Ogni articolo ha un codice ben preciso composto a campi es.
XXXXXAAAABBBCCCC
L'articolo principale è XXXXX gli altri campi sono le combinazioni
possibili (es. l'etichetta, il tipo di fodera ecc, a loro volta articoli)
Nell'anagrafica attualmente è presente  un articolo per ogni combinazione
possibile.
Quindi se XXXXX può avere 3 tipi di fodera e 10 tipi di etichette ci sono
30 articoli.
Capirete che con una struttura del genere, per un articolo "base" mi si
creano anche 2500 articoli in anagrafica.
Il problema non è tanto la velocità del programma, ma piuttosto se il
cliente deve aggiungere un nuovo articoli con n tipi di varianti non può
inserire 2000 articoli.
Come mi consigliate di strutturare il db?
Attualmente è cosi (su 5 livelli invece di 2)
Tabella ARTICOLI
CODICE		TIPO		DESCR
XXXXXAAA	PFINITO		Art.Princ. X variante 1
XXXXXBBB	PFINITO		Art.Princ. X variante 2
YYYYYAAA	PFINITO		Art.Princ. Y variante 1
YYYYYBBB	PFINITO		Art.Princ. Y variante 2
YYYYYCCC	PFINITO		Art.Princ. Y variante 3
AAA		VARIANTE	Variante 1
BBB		VARIANTE	Variante 2
CCC		VARIANTE	Variante 3
Grazie a tutti
-- 
DBMS Firebird
VB6 + Ado

ciao andrea
il problema tuo l'ho capito e stavo cercando un modo per aiutarti.
forse potresti fare:
il database con
Tabella     Articoli
Tabella     Variant
Tabella     ArtVar
così strutturato
                        Articoli  1<-------------->N ArtVar 
N<--------------->Varianti
nel Form anagrafica articolo ci metterai i campi descrizione articolo e 
quello che ti serve
e una lista check con le varianti in cui il cliente selezionerà le varianti 
dell'articolo
a quel punto con il salva
salverai l'articolo in Articoli e l'id delle varianti nel ArtVar
---- forse sono servito a qualcosa forse ho solo scritto caratteri inuli.
io ci ho provato ciao 

 ecc, a loro volta articoli)
L'ideale sarebbe avere una tabella Articoli, una Varianti
e una di relazione (es. Articoli_Varianti)
Articoli
--------
id
descrizione
[ecc...]
Varianti
--------
id
descrizione
[ecc...]
Articoli_Varianti
-----------------
id
idarticolo
idvariante
Per inserire un nuovo articolo, si inserisce un nuovo record
nella tabella Articoli.
Per aggiungere una variante, si inserisce un nuovo record
nella tabella Varianti.
Per aggiungere una variante ad un articolo, si inserisce un
nuovo record nella tabella Articoli_Varianti, in cui
idarticolo e' l'id della tabella Articoli corrispondente
all'articolo, e idvariante e' l'id della tabella Varianti
corrispondente alla variante.
Non e' sempre praticabile la strada delle CheckBox. Nel
tempo ho trovato pratica la soluzione di far inserire (in
fase di modifica dell'articolo) il codice della variante
in una TextBox apposita e con un pulsante aggiungi,
aggiungere ad una listbox/listview la descrizione delle
varianti scelte. In alternativa alla TextBox (se si prevede
che le varianti non siano molte) si puo' usare una ComboBox.
Naturalmente va prevista anche la rimozione.
Sebbene piu' "sporco" dal punto di vista dell'architettura,
puoi mantenere anche una sola tabella per articoli e
varianti, con la differenza che idvariante della tabella
Articoli_Varianti corrispondera' in realta' ad un id della
tabella Articoli. Le visualizzazioni avverrano utilizzando
una condizione sulla SELECT (es. WHERE `tipo`='variante').
Se invece sei obbligato a mantenere la tabella cosi' com'e'
(sic) devi fare tutto il lavoro sporco da codice.
Presupponendo che i tipi siano PBASE PFINITO e VARIANTE
(P=Prodotto), permetti all'utente di inserire il PBASE,
con lo stesso meccanismo evidenziato sopra gli permetti di
scegliere le varianti e poi da codice fai un'INSER per ogni
combinazione possibile (un semplice loop).
hth,
Lokar 

 io ci ho provato ciao
Affatto, il problema più grande è fare un'interfaccia che permetta input
decenti per il cliente.... Per inserire, modificare e cancellare blocchi di
articolo :\
Tnx



si rileggendo con calma il fatto del codice articolo composto da 5 
varianti..
forse la cosa migliore è un TreeView..
ti va di spiegarmi meglio (forse + dettagliato) come è composto l'articolo?
2 menti sono meglio di una :-) 

 2 menti sono meglio di una :-)
Si tratta di cappelli.
Quindi è composto da:
1) Modello (quello che è l'articolo base)
2) Stampo
3) Fodera
4) Etichetta
5) Colore
Quindi abbiamo tipo
1) F5000,F5500
2) S250,S251,S252
3) F556,F560,F700
4) E120,E150,E300
5) C001,C099,C150
Diciamo che il cappello F5000 può essere con stampo (S250,S252).
F5000S250 può avere fodera F560 e basta
F5000S252 può avere fodera (F560,F700)
F5000S250F560 può avere tutte le etichette
F5000S250F700 può avere solo E120 
In pratica un articolo è definito solo quando è specificato tutto fino al
colore. Quindi si creano n combinazioni, che sono la moltiplicazione dei
sottotipi possibili.
Può anche darsi che es.
F5500 può esistere solo come un modello
F5500S251F560E150C150


 combinazione possibile (un semplice loop).
Il problema è che es:
Il cappello AAAA può avere 3 tipi di etichetta.
Il primo tipo di etichetta può avere 10 Colori
Il secondo tipo può avere 1 colore
Il cappello BBBB ha sempre gli stessi 3 tipi di etichetta
Il primo tipo può avere 5 colori (non gli stessi di AAAA come si)
ecc.
Quindi anche a textbox consecutive si trovano a scrivere abbastanza, ed una
voce per volta, tranne l'ultimo livello dove immettono tutti i tipo
possibili in una volta.


>F5000S250 può avere fodera F560 e basta
???
cmq hai pensato con il metodo tipo Wizard...
allora:
un form dove inserisci (o richiami un articolo esistente)
un bottone "Avanti -->"
successiva finestra (o tab di una SSTab) dove scegli gli stampi in base
all'articolo che hai scelto
un bottone "Avanti -->"
successiva finestra (o tab di una SSTab) dove scegli la fodera in base
allo stampo che hai scelto
e via dicendo... 

 e via dicendo...
Si, però c'è sempre il discorso che si automatizza solo l'ultimo livello,
per quelli precedenti si deve comunque metterli uno ad uno.
Almeno a me non viene in mente come fare.
Tnx


 Tnx
un ultima idea potrebbe essere con l'introduzione di Categorie
cioè ogni stampo colore ecc.. appartiene a una o + categorie
quindi dall'anagrafica articoli segli quale categoria desideri e ti caccia
poi la serie di stampi relativi quali poi l'utente sceglie e compone 
l'articolo...
discorso complesso il tuo...
una struttura db di sto tipo:
TABELLE:
Modello: Id, codice
Stampi: id, codice
Colore: id, codice
ecc..
Combinazioni:     ID_Mod, ID_ST, ID_COL .......
quindi di fatto salvi solo il codice dell'modello nella tabella Modello
Nella tabella combinazioni invece salvi i relativi ID quindi per risalire 
all'articolo finito:
select * from modello,stampi,colore,combinazioni where 
modello.id
=combinazioni.id_mod and
stampi.id
=combinazioni.id_st and 
colore.id
=combinazioni.id_col where 
modello.id
=F5000
........