Newsgroup: it.comp.software.database
Titolo: database di telefoni cellulari...

Come strutturereste voi un db contenente informazioni relative ai vari 
telefoni cellulari?
(I soluzione)
- tabella `marche`: `id`,`marca` (es: 3,Nokia)
- tabella `modelli`: `id`,`id_marca`,`modello` (es: 5,3,3310)
- tabella `descrizione`: `id`, `id_modello`, `caratteristica_A`, 
`caratteristica_B`,...,`caratteristica_N` (es: 1,5,'T9','si',...,NULL)
Svantaggio: se un giorno si dovesse aggiungere una nuova funzionalità, 
andrebbe ristrutturata tutta la tabella `descrizione` (con un ALTER 
TABLE).
(II soluzione)
- tabella `marche`: `id`,`marca` (es: 3,Nokia)
- tabella `modelli`: `id`,`id_marca`,`modello` (es: 5,3,3310)
- tabella `funzionalita`: `id`,`nome_funzionalita` (es: 1,'display a 
colori')
- tabella `descrizione`: `id`, `id_funzionalita`, `id_modello`, 
`info_aggiuntive` (es: 7,1,5,'65.000')
Svantaggio: gestione più complessa, e dimensione della tabella 
`descrizione` potenzialmente più grande (nella prima soluzione il 
numero di righe è pari al numero dei cellulari inseriti; nella seconda 
soluzione invece è pari, al massimo, al prodotto tra le funzionalita e 
il numero dei cellulari [supponendo che tutti i cellulari abbiano tutte 
le funzionalita] ).
(III soluzione)
Avete altre idee su come strutturare il db in questo caso?
--
rob4you

 Non hai detto a che ti serve questo database.
Lo ho specificato all'inizio di questo messaggio.
Se ora è più chiaro, gradirei sapere appunto come Voi strutturereste il 
db in questo caso.
--
rob4you

 
Non sono daccordo.
Serve come vincolo.
Saluti  Manlio Perillo

 Serve come vincolo.
Diciamo che permette una gestione più "libera" al verificarsi di alcune 
circostante, come ho cercato di spiegare nel mio mex precedente.
Pongo quindi anche a te la stessa domanda: come struttureresti il db?
Ah, preciso che il db è ancora da costruire per intero.
Quindi ogni idea è ben accetta, purché sia supportata da pro e 
eventuali contro. ;-)
--
rob4you

 programma funziona/funzionera'. 
Ah, dimenticavo che il tutto dovrebbe essere accessibile da web, sia la 
parte relativa all'inserimento, sia la parte relativa alla ricerca.
Quindi?
--
rob4you

 direttamente nel codice dell'interfaccia.
Quindi, se non ho capito male, una tabella soltanto?
Perché, stando alle tabelle di supporto che avevo introdotto io, tu non 
le considereresti proprio, quindi non resterebbe che una tabella 
principale.
Ultima cosa: posto eventualmente l'uso di una tabella singola, tu 
categoricamente sconsigli l'uso di una tabella avente, oltre a 
`marca`,`modello`, anche N campi, ciascuno corrispondente a una 
determinata caratteristica, con dentro scritte le info relative a quel 
campo?
es (1):
marca,modello,colore,peso,fotocamera:
(nokia,3310,blu,100g,NULL),
(nokia,6131,nero,80g,1.3mp)
Qindi, al posto di questa soluzione tu preferisci una soluzione del 
tipo:
es (2):
marca,modello,caratteristica,descrizione:
(nokia,3310,colore,blu),
(nokia,3310,peso,100g),
(nokia,6131,colore,nero),
(nokia,6131,peso,80g),
(nokia,6131,fotocamera,1.3mp)
Come si può osservare però, per tenere le stesse informazioni, in un 
caso ho bisogno di due sole righe, nell'altro ne necessito di 5 
(appunto un numero minore o al più uguale di 2x3 [cioè num. di 
cell]x[num. di caratteristiche]. Lascio immaginare come aumenterebbe 
questo numero considerando più cell o più caratteristiche).
Ovviamente l'esempio (1) e (2) hanno pro e contro. Considerato l'ambito 
specifico, su quale faresti affidamento?
--
rob4you

 al codice del programma di gestione ne' alla base dati.
Anche qualora le righe della tabelle, nelle due soluzioni prospettate, 
dovesserro essere in un caso meno di un migliaio, e nell'altro anche 
quaranta-cinquantamila?
--
rob4you

 telefoni cellulari?
Raccomando una googlata su "EAV" in questo ng.

> Raccomando una googlata su "EAV" in questo ng.
EAV sta per cosa?
Ente Autonomo Volturno?
ElettroAgopuntura secondo Voll?
Erste Allgemeine Verunsicherung?
Entity-Attribute-Value? (forse si, forse questo) :-)
On the web ci si perde, dai qualche dritta in più please.
--
rob4you

> Entity-Attribute-Value? (forse si, forse questo) :-)
http://en.wikipedia.org/wiki/Entity-Attribute-Value_model
D'accordo, ci siamo, ma appunto non sono tutte rose e fiori.
Dipende dal caso specifico.
Vorrei capire se QUESTO è il caso specifico o meno.
--
rob4you

 EAV sta per cosa?
E-Leggi-Bene ;-)
Se ne è parlato... parecchio.
bye

 Se ne è parlato... parecchio.
ELB o EAV? :-)
Dai scherzi a parte, posto che io, nel mio post iniziale, ho mostrato 
sue soluzioni, di cui una è quella classica, e l'altra è proprio quella 
EAV, desideravo avere opinioni personali a riguardo su quale fosse 
preferibile, ovviamente in questo SPECIFICO scenario.
Magari faccio un semplicissimo esempio qui:
- ho mille modelli di telefoni cellulari, e cinquanta caratteristiche 
da considerare
Se uso la soluzione "tradizionale" 
(id,caratteristica1,...,caratteristica50), in tabella avrò 1000 righe.
Se uso invece la soluzione EAV (id,attributo,valore), in tabella avrò 
un numero minore o uguale a 1000x50, cioè 50000. In altre parole, a 
vantaggio della flessibilità, aumento di un ordine di grandezza "e 
mezzo" il numero delle righe.
Mi domando, quindi, una tale scelta, considerando il caso specifico dei 
cellulari, è giustificata o no?
A pensarci bene, in due anni, l'unica innovazione introdotta nel campo 
dei cellulari è stato il "tvfonino".
Questo avrebbe comportato, in un lasso temporale di due anni, adottando 
una struttura "tradizionale" della tabella, UNA SOLA volta, una ALTER 
TABLE della tabella.
Ecco perché io continuo a chiedere, e gradirei avere una risposta 
giustificata e supportata magari da esempi, quale metodo è preferibile 
IN QUESTO CASO.
--
rob4you

 QUESTO CASO.
Vuoi una risposta definitiva? E' SEMPRE sbagliato farlo.
Semplicemente qualche volta non paghi per gli errori, e il
risparmio di tempo apparentemente conviene.
Hai mai giocato alla roulette un sistema che i primi colpi vinci,
e poi di colpo perdi tutto quello che hai guadagnato, e anche di più?
La teoria relazionale è un sistema di regole che permette il
tanto desiderato obiettivo di dichiarare uno schema "giusto".
Se non si pone un punto fermo, ogni cosa diventa opinabile e può
cambiare da un momento all'altro.
D'altronde, tu stesso dici che per convenienza faresti quello schema,
ma analizzando bene, la convenienza non ci sarebbe stata.
bye

> Vuoi una risposta definitiva? 
Non voglio una risposta definitiva.
Voglio solo sapere la risposta di N persone, relativamente a questo 
caso, con N tendente a infinito.
Perché in questo modo, se c'è una soluzione "migliore" rispetto alle 
altre, la risposta convergerà.
In una scelta, tanto fa l'esperienza.
Se vogliamo andare al casinò va bene, andiamoci pure.
Ma qui, io stavo chiedendo un opinione personale. Opinione dettata da 
tanti fattori, in primis l'esperienza.
Non fare una scelta mi sembra un atteggiamento di ignavia, significa 
non esporsi.
E la mia scelta definitiva, proprio perché voglio che sia ponderata, 
desidero che sia frutto non soltanto dello studio teorico della 
questione, ma anche dei pareri personali dei componenti di questo ng.
Va benissimo dire "studiate l'EAV" (che se leggevi il mio primo 
messaggio avresti visto che era esattamente una soluzione che io 
proponevo).
Ma serve a ben poco se non si aggiunge: "in questa situazione IO 
personalmente opterei per questa scelta, perché ecc. E invece non 
sceglierei quest'altra cosa perché ecc."
In un ng ci si confronta con le idee. Se tu non dici la tua idea, con 
motivazioni, che confronto è?
Tutto IMHO.
--
rob4you

 proponevo).
Se ti riferisci a me, le mie opinioni sono ben note a questo ng.
Per due volte ti ho detto di cercare i thread passati, in cui ne
ho discusso in lungo ed in largo, in cui avresti scoperto sia il
mio pensiero sia che l'eav è un errore.
Devo dedurre che non l'hai fatto dato che continui a spingere
verso simili argomenti.

 mio pensiero sia che l'eav è un errore.
Dal tuo primo messaggio in questo thread non avevo capito che dicevi di 
cercare EAV "internamente" a questo ng. Pensavo stessi dando un 
consiglio più generale a tutti i lettori del ng, di cercare su google 
"EAV" (ahimé son stato indotto in errore dal tuo primo messaggio: 
"Raccomando una googlata su "EAV" in questo ng").
Ora che mi è più chiaro cosa intendi, posso muovermi in direzioni più 
precise.
Di conseguenza, se reputi l'EAV un errore, deduco che tu ti 
orienteresti verso una strutturazione "attribute-value", piuttosto che 
"eav"?
Non so se hai letto tutto il thread, ma io stesso avevo proposto 
diverse soluzioni, evidenziandone sommariamente pro e contro. Motivo 
per il quale chiedevo un parere più o meno "autorevole" anche da parte 
degli altri membri.
Se ci fossimo capiti sin dall'inizio forse avremmo evitato parte di 
questa 'querelle'. ;-)
--
rob4you

 di questa 'querelle'. ;-)
No problem, l'importante è risolvere.
In casi simili si cerca di modellare un numero limitato di
colonne, ossia quelle che userai sicuramente e che sono
caratteristiche ragionevolmente comuni a tutti i modelli.
bye