[MYSQL] Nomi Colonne con variabili php

[salcam]

Salve a tutti,
vorrei sapere se è possibile aggiungere delle colonne, in una tabella di un database sql, che abbiano per nome una variabile php.

Quello che vorrei ottenere è un modo dinamico di aggiornare la tabella.

Questo perchè voglio che l'utente non sia limitato nel numero di campi da inserire, quindi se il numero di campi scelti è maggiore di quelli presente nella tabella, deve aggiungere ulteriori colonne alla tabella con un nome ben preciso.

Ad Esempio:

ALTER TABLE note_cliente ADD 'Prod_$i' VARCHAR(50)

dove $i è una variabile che va incrementandosi.

Grazie in anticipo.

[frinkia]

Non sta di certo a chi usa il database decidere lo schema. Quello che vedo qui sopra e' un orrore di normalizzazione. Prendi un'altra strada.

[salcam]

forse mi sono spiegato male.

Devo semplicemente permettere al client di aggiungere nuove colonne alla tabella qualore ci sia bisogno.

Cmq grazie lo stesso per aver risposto.

Sul consiglio di cambiare strada, allora mi saprai dare qualche dritta.

[piero.mac]

diciamo che la strada che avresti scelto di far gestire a piacere dell'utente la tabella va contro ogni logica di programmazione.

La struttura del db che viene alterata in modo imprevedibile impedisce di sviluppare lo script che la deve gestire. E' in altre parole la struttura del database e' quella su cui si deve costruire lo script di gestione. Non viceversa.

[salcam]

Allora mettiamola così.

Io ho la mia tabella sql 'fatture' con i campi: N_Fattura, Data, Cod_Cliente.

Quando l'utente vuole creare la fattura andrà ad aggiungere svariati prodotti, di cui, io programmatore, non posso sapere il numero.

Quando questa fattura deve essere memorizzata, per poi magari essere modificata, io andrò a memorizzare i campi N_Fattura, Data e Cod_Cliente nella tabella 'fatture'. In questa tabella devo memorizzare anche il codice di ogni singolo prodotto e la relativa quantità, quindi avrei pensato di creare un campo(colonna) per ogni singolo prodotto.

Allora ci sono due strade:

1) Creare in fase di programmazione 20 campi (tanto in un fattura al massimo andranno inseriti 15-20 prodotti) che contengono il codice del prodotto ed altri 20 che contengono le quantità (un pò assurdo perhè troppo statico)

2) Non so che strada prendere, dato che la proposta fatta nel post precedente (aggiungere dinamicamente colonne), è sbagliata.

Aiutatemi vi prego

[piero.mac]

fai una tabella prodotti, una clienti, una fatture

questo solo per un esempio molto massimale...

clienti

id_cliente
dati cliente blabla


prodotti

id_prodotto
descrizione...costo ...blabla

fatture

id_fattura
data
n_fattura
id_cliente
id_prodotto


ripeto molto massimale e generico.... ma la via e' questa. Ogni ordine un record, ogni cliente un record, ogni prodotto un record...

[salcam]

si però in id_prodotto non ci va un solo prodotto, bensì più prodotti

[frinkia]

La strada della normalizzazione e' sostanzialmente questa:

1 concetto = 1 tabella ( = 1 oggetto programmando in OOP)

Come ti e' gia' stato suggerito, devi creare una tabella per ogni entita' che vuoi rappresentare. La scelta del termine entita' non e' casuale: tutta la teoria dei database relazionali e' basata sui concetti di entita' e relazione (di qui i famosi diagrammi e/r).

Devi determinare ogni entita' e che tipo di relazione ha con le altre entita'.

Tipico esempio: le entita' da rappresentare sono essenzialmente tre:

Cliente
Prodotto
Fattura

Ad ogni proprieta' singola di una entita' corrisponde una colonna sul database.

Per Cliente e Prodotto, la cosa va da se'.

La fattura, e' una entita' che va rappresentata a se' e ha delle proprieta' proprie (data di emissione, stato di pagamento..), e alcune in relazione ad altre entita':

La fattura e' emessa verso un solo cliente (relazione uno a molti), e composta da molti acquisti di prodotti. Piu' prodotti possono essere presenti in una fattura, e lo stesso prodotto puo' essere presente in piu' fatture: relazione molti a molti. Le relazioni uno a molti si fanno con le foreign keys, le relazioni molti a molti si fanno con delle tabelle di collegamento, di relazione, insomma, che spesso hanno delle proprieta'.

Ad esempio, nel caso specifico dovresti probabilmente creare una tabella di relazione ACQUISTO che lega FATTURE e PRODOTTI; siccome ogni acquisto ha proprieta' diverse, oltre a legare l'acquisto di un PRODOTTO ad una FATTURA (con due foreign keys a ID_PRODOTTO e ID_FATTURA), verosimilmente dovrai mantenere delle proprieta' dell'acquisto in se': ad esempio, uno stesso PRODOTTO puo' essere venduto a uno sconto diverso a seconda della FATTURA, e quindi dovrai avere una colonna nella tabella ACQUISTI con lo sconto (e cosi' via).

Prima di addentrarti ulteriormente nelle problematiche, ti consiglio caldamente di darti un'occhio in libreria o in rete a qualche libro o almeno tutorial sulla teoria relazionale; oltre a imparare cose che non puoi non sapere se sei uno sviluppatore, ti risparmierai apocalittici gatte da pelare in futuro. Uno schema di database denormalizzato, infatti, e' sempre fonte di problemi molto difficili da risolvere.

[salcam]

Prima di tutto ti ringrazio per i tuoi consigli, ma forse il mio problema è tutt'altra cosa.

Cmq per quanto concerne i libri da leggere ecc., forse ne ho letti fin troppi e questi sono i risultati, cioè mi impappino in delle stronz...

Grazie lo stesso