Newsgroup: it.comp.software.database
Titolo: articoli, varianti e misure

questo e' un post del 2003 a cui nessuno diede risposta :o)
spero che oggi sia + apprezzato :o)
========================
ecco il problema
-
tabella Articoli:
articoloID (PK)
descrizioneArt
tabella Varianti:
variantiID (PK)
descrizioneVar
tabella Numerate (le misure delle calzature :o)
numerataID (PK)
descrizione
ora devo creare una tabella fra
gli articoli, le numerate e le varianti
che avra' come chiave primaria composta
il codice articolo e il codice variante
(ogni articolo-variante la propria numerata...)
articoloID (FK articoli.articoloID)
variantiID (FK varianti.variantiID)
numerataID (FK numerate.numerataID)
(PK articoloID, variantiID, numerataID)
ora succede che non tutti gli articoli hanno la variante!
ma con questa architettura ovviamente non posso assegnare un valore 
NULL
nel campo variante, per il fatto che il campo e' parte di una
chiave primaria... :o(
che mi consigliate di fare?
1. faccio caricare una variante di default per tutti gli articoli 
(potrei far caricare una variante del tipo *al campione* o *nessuna* ma 
il problema e' che ha poca logica...)
2. utilizzo un contatore per ogni coppia articolo-variante (si 
potrebbe... ma sputtano l'integrita' dei dati)
3. tolgo la chiave referenziale (idem come sopra...)
4. uso due tabelle: una per gli articoli con variante (come sopra)  una 
per gli articoli senza variante (forse la migliore a livello logico, ma 
molto, molto, complessa...)
qualsiasi idea, conglio, link e' ben accetto
grazie molte
Rob

 il problema e' che ha poca logica...)
[cut]
Direi di utilizzare questa soluzione anche perché è assolutamente logica 
  nel senso che "questo articolo non ha varianti" è pur sempre una 
informazione.
In genere le varianti si distinguono a livello di codice articolo 
comunque se tu hai fatto questa scelta avrai avuto le tue ragioni.
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa 
scrittura, non so per chi, non so più intorno a che cosa...
U. Eco

 In genere le varianti si distinguono a livello di codice articolo comunque 
puoi farmi un esempio per favore?
grazie
Rob

 puoi farmi un esempio per favore?
Volevo dire che nella tabella articolo, che individua una entità 
fisicamente determinata, metterei un codice univoco.
Esempio semplificato:
table articoli
*fornitore
*modello
*variante
*misura
...
* = PK
eventualmente completate da tables aggiuntive per fornitori, modelli, 
varianti, movimenti di magazzino (acquisti/vendite) ecc.


 *variante
si, ma in questo modo puoi avere una sola variante per articolo...
sbaglio?
io vorrei N varianti per articolo.. :o)
ciao
Rob

 sbaglio?
Puoi averne quante ne vuoi, ognuna col suo codice

 qualsiasi idea, consiglio, link e' ben accetto.
Aristotele: "Una cosa e' una cosa in particolare, e nessun'altra;
oppure non e' nulla!" :-)
bye

 *nessuna* ma il problema e' che ha poca logica...)
quindi con una tabella di lookup, raggruppo le chiavi primarie di 
articoli, colori, taglie
perche come detto sopra un capo di abbigliamento ha sempre un colore e 
una taglia...
che ne pensi?
grazie
Rob

 che ne pensi?
E' la soluzione piu' semplice, corretta e redditizia.
Il punto era soprattutto constatare che "Variante" e' un articolo
di vendita, per cui per completare andrebbe rinominata in
qualcos'altro per non generare confusione (es. "Modelli").
Risolto questo, mi chiedo allora la tabella Articoli cosa
identifica in realta' (certamente non un articolo inteso in senso
comune; temo che anche questo concetto non sia completamente
corretto).
bye 

> The man with two watches ha detto questo martedì :
grazie per i tuoi consigli, mi hai dato ottimi spunti!
1k grazie :o)
Ron