Newsgroup: it.comp.software.database
Titolo: Database con numero variabile di colonne

Ciao a tutti.
Sto progettando un database che deve gestire una serie di prodotti.
Ognuno di questi prodotti ha un certo numero di caratteristiche (con i
relativi valori) che però possono cambiare nel tempo. Possono quindi
essere eliminate e aggiunte le varie caratteristiche.
Vorrei chiedervi un parere su come affrontare il numero variabile di
colonne. Io ho pensato a due approcci possibili:
- alterare le tabelle quando arriva la notifica dell'aggiunta di una
nuova caratteristica
- tenere in una tabella le caratteristiche
Al momento mi sembra più vantaggiosa la seconda, soprattutto per
questioni di spazio, anche se a me piacerebbe avere una cosa gestibile
interamente "sui dati" piuttosto che dover alterare la struttura.
Che ne dite? Ovviamente è ben accetto qualunque suggerimento per una
soluzione diversa!
Grazie in anticipo a chi risponderà.

 Al momento mi sembra più vantaggiosa la seconda,
La *prima*, scusate.


ed invece la seconda :)
tu hai la tabella degli articoli,
ed ogni sua caratteristica identificata,
cambia caratteristica cambia id .
naturalmente avrai l'anagrafica caratterische,
che ti descrivera' le caratteristiche
felice_pago
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 che ti descrivera' le caratteristiche
Al momento dovrei fare una cosa del genere:
caratteristica con suo id.
valori della caratteristica, che si riferiscono a lei tramite
id_caratteristica, ognuno con un id_valore.
A questo punto però, per fare l'anagrafica prodotti, in cui segno i
valori delle caratteristiche possedute dal prodotto, non avrei una riga
per ogni valore della caratteristica?
Una cosa tipo:
id_articolo - id_caratteristica - id_valore
Mi preoccupa il fatto che gli articoli sono circa 200k, e in media
hanno una ventina di caratteristiche.


ma devi fare un db relazionale ?
allura
tabella articoli
id articolo, e tutte le colonne possibili ed immaginabil per "descrivere"
l'articolo
anagrafica caratteristica
id caratteristica definizione caratteristica ecc . . .
quando nasce 1 articolo nasce cone delle caratteristiche, che saranno
identificate
dall'id nella riga articolo, e definizione nella riga corrispondente della
tabella
caratteristiche.
ergo
una ventina di caratteristiche, una ventina di colonne,
e la tabella caratteristiche una ventina di righe !
mi sono capito ?
per complicare:
una caratteristica se evolve,
il suo id che fine fa ?
e tutti gli articoli collegati ?


 e tutti gli articoli collegati ?
funziona (deve funzionare) così:
I prodotti hanno un id e delle caratteristiche comuni a tutti, che
metto in una sola tabella.
Poi i prodotti hanno una serie di caratteristiche con valori
predefiniti (ed. per un televisore potrei avere "tipo" che può
assumere come valori "plasma", "lcd", "crt" e "retroproiezione").
Questo perché ricevo un invio di dati settimanali, e chi usa il db
vuole poter rinominare sia le caratteristiche che i valori, ma per
gestire poi l'arrivo di nuovi prodotti con la traduzione delle
caratteristiche, devo tenere in memoria i vecchi nomi.

interamente "sui dati" piuttosto che dover alterare la struttura.
Questo design si chiama EAV (entity-attribute-value), e dal punto
di vista relazionale è un errore (naturalmente da un altro punto di
vista può essere considerato una "feature" :-> ). In pratica consiste
nel codificare quello che prima era una tabella (entity) e/o una
colonna (attribute) in un valore.
Come prima ed immediata conseguenza, hai trasformato i metadati in
dati, cambiandone per sempre modo di trattarli nel codice che lo
manipola (permettendo, ad esempio, il passaggio silenzioso di
quello che prima veniva segnalato come errore bloccante).
Secondo, lo schema del database è ora in mano all'utente,
il quale sicuramente non mancherà di combinare casini.
Terzo, hai dumbizzato il db, il quale non è in grado di capire uno
schema di tipo IDVAlore - Descrizione, rendendone più debole il
significato, più difficili le inferenze, e in definitiva diminuendone
l'utilità (un modello di dati dà la sua utilità quando ci si
riferisce ad un oggetto intendendo precisamente quella cosa in
particolare e nient'altro in generale).
Quarto, applicare l'integrità su una tale tabella è un'avventura
tutta da esplorare.
Quinto, come conseguenza di III e IV, probabilmente dovrai fare
ricorso all'infame application-managed integrity, inserendo una
robusta quantità di IF nel codice (ora l'unico in grado di
"capire" i dati).
Sesto, è stato statisticamente dimostrato in maniera scientifica che
chi implementa un tale schema tromba meno.
Naturalmente, un design relazionale ha un prezzo: bisogna aggiungere
una tabella per ogni entità, ed una colonna per ogni attributo.
Questo, nel tuo caso che hai 200.000 articoli, con 20 caratteristiche
per ogni _tipo_ di articolo (quindi non necessariamente 4.000.000),
è un lavoro che fa tremare le ginocchia.
Per fare una applicazione di e-commerce (che mi sembra di aver capito
devi fare tu) prova ad ispirarti ai siti tipo amazon, ebay, chl;
vedrai che di solito si modellano solo una limitata quantità di
attributi, gestendo il resto più o meno come stringhe varie (un
mio collega lo chiama "misto mare" :-)
ciao

 
MA LOL!!!!!!!  :)
questo lo convincerà sicuramente più dei precedenti 5 punti!!

 caratteristiche, devo tenere in memoria i vecchi nomi.
tab_prodotto:
id_prod dersc_prod id_car1 id_car2 id_car3 id_car4
ergo abbiamo scolpito nella pietra che il prodotto sara' descritto
max con 4 caratteristiche
adesso quali sono queste caratteristiche
tab_car:
id_car descr_car
per facilitare potresti "assimilare" sia i prodotti che le caratteristiche,
nel senso che se metti certi prodotti nell'inserirne le caratteristiche,
ti vengono fuori solo quelle che ti servirebbero per descriverlo, e via
dicendo per tutto lo schema .
ps:
studia !


 mio collega lo chiama "misto mare" :-)
Ecco, mi era venuta in mente una soluzione del genere: creare una solo
colonna "caratteristiche tecniche", che come valore ha una stringa con
tutti i valori, con un separatore definito.
Questo approccio però per me non è realizzabile, o almeno non mi
sembra: infatti se non tratto ogni caratteristica e ogni valore
assumibile dalla caratteristica *ANCHE* come un "dato", non mi è
possibile permettere all'utente di rinominarli in modo trasparente.
Sostanzialmente al momento io ho una tabella con le caratteristiche
fatta così:
ID_tipo_prodotto, ID_caratteristica, nome originale (sono obbligato a
tenerne traccia), nome personalizzato
una tabella con i valori fatta così
ID_caratteristica, ID_valore, nome originale, nome personalizzato
mentre poi la tabella di ogni tipo di prodotto ha come colonne le
caratteristiche ad esso associate, e come dati i valori delle
caratteristiche che descrivono il prodotto.
Spero di essere stato chiaro, scusa il post molto lungo :)
ciao!

 studia !
Credo di aver studiato :)
Probabilmente non mi ero spiegato bene all'inizio, oppure non ho capito
ancora adesso e in tal caso scusami.
Ciao!

 modifica, di eliminazione e di aggiunta.
che db usi ?
ma penso che potresti agevolmente utilizzare almeno 128 colonne,
che dici bastano ?
che poi, non tutte le colonne di una riga sono valorizzate,
fa niente


 fa niente
Mmm, questo penso si possa fare. Non credo si arriverà mai a così
tante caratteristiche. Non è una soluzione pulitissima ma non lo sono
nemmeno le altre.
Faccio un tentativo, grazie del suggerimento :)

fatta così: [...]
Può andare, ma prova a pensare uno schema semi-eav ancora più
semplice, composto da una tabella "base" e una con le caratteristiche
"opzionali", tipo:
Articoli {Codice, Nome, Prezzo, Giacenza}
Caratteristiche {CodiceArticolo, Descrizione[, Valore]}
Più semplice tieni la seconda, meno ti incasini, e ricordando
comunque che non puoi farci troppo affidamento perché "problematica".
ciao

 comunque che non puoi farci troppo affidamento perché "problematica".
D'accordissimo, infatti avevo già fatto così, ma come ho detto sopra
avevo voluto semplificare (sbagliando) la questione riportandola qui.