|
|||||||
|
|
|
![]() |
|
|
Strumenti |
|
|
#1 |
|
Senior Member
Iscritto dal: Sep 2010
Messaggi: 718
|
[SQL/PHP] - Colonne dinamiche
Salve gente,
ho un problema con la gestione di una base di dati e relativa web app in PHP. Vi faccio il punto della situazione! Ho da gestire dei prodotti, questi prodotti hanno dei campi obbligatori, altri (opzionali) cambiano in base alla tipologia di prodotto. Le tipologie quindi, sono una collezione di questi campi opzionali, a loro volta possono essere modificati/rimossi da un addetto ai lavori. Esempio pratico: -ProdottoA -nome: XX -peso: YY -tipologia: ferro -peso specifico (opzionale): XYW -lucententezza (opzionale): WYXX -ProdottoB -nome: HJPA -peso: GHH -tipologia: carbone -derivazione (opzionale): BLABLA -data acquisto (opzionale): GG/MM/AAAA Quindi, le tipologie "ferro" e "carbone" hanno campi diversi opzionali. Un admin può decidere di aggiungere o rimuovere o cambiare uno di questi campi, in base alle esigenze, e può anche inserire nuove tipologie. Detto ciò, un "operaio" che deve inserire un prodotto immette i campi obbligatori (nome, peso), seleziona la tipologia ed escono fuori i campi che dipendono dalla tipologia (opzionali, cioè può anche non inserirli). Partiamo dal fatto che, con le conoscenze derivate dalle lezioni universitarie, questo problema non sono in grado di risolverlo a dovere da solo (nemmeno i colleghi). Non so proprio come impostare la base di dati e come generare colonne dinamiche per l'eventuale modifica dei campi opzionali. Ok, in realtà l'idea c'è ma è così: - table tipologie (id, nometip) - table campi (id, idtipologia, nome_campo) - table relazione_tipologie_campi (id, idtipologia, idcampo, idprodotto, valore) - table prodotti (id, nome, peso, tipologia) A me sembra proprio brutta come cosa e nemmeno tanto buona, ma al momento non sono in grado di trovare una soluzione migliore. Avete suggerimenti?
__________________
Ho venduto a: micanto1(muletto)-franzgranata(Alimentatore)-piff84(Desktop)-s3n3ca(netbook)- helmen84(Nexus 5) Ultima modifica di isee : 29-12-2013 alle 15:20. |
|
|
|
|
|
#3 |
|
Member
Iscritto dal: Apr 2008
Messaggi: 125
|
Così, a prima vista, io farei così...
Ogni tipologia con la sua tabella dedicata nella quale ogni record rappresenta un campo. Poi, un'unica tabella prodotti la quale contiene tutte le colonne di tutte le tabelle tipologie... In pratica: table ferro id1 - nome id2 - peso id3 - peso specifico id4 - lucentezza table carbone id1 - nome id2 - peso id3 - derivazione id4 - data acquisto table prodotti (con tutti i campi delle tipologie) tipologia - nome - peso - peso specifico - lucentezza - derivazione - data acquisto In questo modo non dovrebbero esserci grossi problemi nel caso di aggiornamenti da parte dell'admin... Nel caso di una nuova tipologia si creerebbe una nuova tabella dedicata; nel caso di un nuovo campo, una semplice insert nella table tipologia interessata e un'aggiunta di colonna alla table prodotti (se non è già presente un campo comune...). Poi, con javascript, php e i form html puoi gestire tutto il resto... Ciao e buon anno. Ultima modifica di tigroneveloce : 01-01-2014 alle 15:18. |
|
|
|
|
|
#4 |
|
Senior Member
Iscritto dal: Sep 2010
Messaggi: 718
|
Ciao e buon anno. In questo modo, io creo una tabella prodotti con colonne fissate anche per i campi della tipologia, ma questi possono aumentare o diminuire. Avevo pensato anche io a questa soluzione, però non funziona perché se ho una tipologia con 20 campi ed una con 200 campi (tutti diversi), che succede poi alla tabella prodotti?
__________________
Ho venduto a: micanto1(muletto)-franzgranata(Alimentatore)-piff84(Desktop)-s3n3ca(netbook)- helmen84(Nexus 5) Ultima modifica di isee : 01-01-2014 alle 15:54. |
|
|
|
|
|
#5 |
|
Member
Iscritto dal: Apr 2008
Messaggi: 125
|
Non succederebbe niente alla tabella prodotti; al limite ci si troverebbe con un numero di campi inutilizzati...
Piuttosto, è quel "diminuire" che non mi convince... Che cosa intendi, perdere i dati? Perché se, per esempio, il campo "derivazione" della tipologia "carbone", viene eliminato dall'admin, allora non recuperi più il valore contenuto (BLABLA). |
|
|
|
|
|
#6 |
|
Senior Member
Iscritto dal: Sep 2010
Messaggi: 718
|
Ma sarebbe una cosa davvero poco elegante, una soluzione bruta e probabilmente evitabile. Personalmente, non prendo proprio più in considerazione una simile alternativa.
Rimango in attesa di altri aiuti comunque
__________________
Ho venduto a: micanto1(muletto)-franzgranata(Alimentatore)-piff84(Desktop)-s3n3ca(netbook)- helmen84(Nexus 5) |
|
|
|
|
|
#7 |
|
Senior Member
Iscritto dal: Feb 2004
Città: milano
Messaggi: 2148
|
A mio avviso ciò che hai pensato è proprio la soluzione più corretta. Non mi viene in mente altro di buono ed è ciò che farei pure io.
Cosa non ti convince? |
|
|
|
|
|
#8 |
|
Senior Member
Iscritto dal: Sep 2010
Messaggi: 718
|
Leggevo qualche tempo fa del fatto che è possibile creare colonne virtuali dinamicamente, però era qualcosa che attualmente va oltre le mie possibilità di studio. Magari poteva esistere qualcosa di simile, fattibile in sql e che io non ero a conoscenza, oppure un'alternativa migliore rispetto a quella che ho trovato io. Nel senso, una volta creata la tabella dei campi delle tipologie con i rispettivi valori inseriti per ogni prodotto, mi sorge il dubbio che effettivamente sia essa stessa una soluzione poco elegante.
__________________
Ho venduto a: micanto1(muletto)-franzgranata(Alimentatore)-piff84(Desktop)-s3n3ca(netbook)- helmen84(Nexus 5) |
|
|
|
|
|
#9 |
|
Senior Member
Iscritto dal: Mar 2003
Città: Perugia
Messaggi: 16302
|
a me la tua soluzione sembra la migliore..
|
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 17:28.




















