Organizzare DB per permettere una particolare funzionalità

[Alhazred]

Il titolo è un po' criptico, ma non sapevo che scrivere.

Vengo al dunque.
Devo realizzare un componente per Joomla che permetta di realizzare dei preventivi online, quindi lato frontend si vede una form, la si compila, si fa il submit e si ottiene il preventivo.
Lato backend c'è la funzionalità particolare, ovvero deve essere possibile aggiungere nuove opzioni direttamente dal pannello di controllo.
Non parlo di nuove voci nei menu select, ma proprio nuovi campi nella form.

Ecco, sto avendo problemi a progettare le tabelle del database.
Al momento sto pensando a 2 tabelle
1) tabella contenente i campi che la form dovrà mostrare, qui ci metterei solo il tipo di campo, il nome e dove andare a prendere le opzioni nel caso si tratti di un campo select

2) tabella contenente le possibili scelte con associata ad ognuna il prezzo relativo, in questa tabella ci sono anche i dati che associano le opzioni ai corretti campi select.

Il mio problema è la realizzazione delle parti in rosso, ma se avete consigli per semplificare il tutto vanno bene anche quelli.

[bubi1]

Hai presente le "varianti" dei prodotti del virtuemart?
Perche' non provi a fare una roba del genere, con un parser basilare?

[Dascos]

Puoi fare così:
Tabella che contiene i campi "extra"

CREATE TABLE IF NOT EXISTS `pf_fields_data` (
  `pf_id` smallint(5) NOT NULL AUTO_INCREMENT,
  `pf_title` varchar(250) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `pf_desc` varchar(250) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `pf_content` text COLLATE latin1_general_ci NOT NULL,
  `pf_type` varchar(250) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `pf_not_null` tinyint(1) NOT NULL DEFAULT '0',
  `pf_max_input` smallint(6) NOT NULL DEFAULT '0',
  `pf_position` smallint(6) NOT NULL DEFAULT '0',
  `pf_show_on_reg` tinyint(1) NOT NULL DEFAULT '0',
  `pf_input_format` text COLLATE latin1_general_ci NOT NULL,
  `pf_admin_only` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`pf_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1 ;

così hai una struttura che accoglie la definizione dei campi extra.
Poi un'altra tabella del tipo

CREATE TABLE IF NOT EXISTS `pfields_content` (
  `member_id` mediumint(8) NOT NULL DEFAULT '0',
  `updated` int(10) DEFAULT '0',
  `field_1` text COLLATE latin1_general_ci,
  `field_2` text COLLATE latin1_general_ci,
  `field_3` tinyint(4) NOT NULL DEFAULT '1',
  `field_4` tinyint(1) NOT NULL DEFAULT '1',
  PRIMARY KEY (`member_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

che invece raccoglie i contenuti campi extra. In questo esempio i campi extra sono 4.
Il legame lo fai semplicemente recuperando gli extra dell'utente, sapendo che field_1 corrsiponde alla definizione che ha id = 1.
Ovviamente quando aggiungi un campo extra ti tocca modificare la tabella content aggiungendo il campo "field_x".

Non è il massimo della praticità, ma ti risolve qualche problemino. Es: il campo è una select box.
Per inserire i possibili valori (ipotizzo che siano fissi, ovviamente) del tipo "uomo, donna, non dichiarato, ti basta inserire per esempio "m=Uomo|f=Donna|?=non dichiarato" in pf_content. Quando vai a recuperare il dato dell'utente, nel field_x corrispondente troverai per esempio "m" che, stante la definizione pf_content, significa "uomo".

Spero di esserti stato d'aiuto.

[Santino83_02]

non ho capito il punto 2, ma sul punto 1 puoi anche mettere un campo in cui scrivere l'oggetto delegato a stampare la select, e delegare all'oggetto il compito di popolare la select...

nel senso se la select serve per le regioni, metti nel campo "PrintSelectRegioni" e al momento della stampa istanzi l'oggetto che si andrà a prendere le regioni dal db e le stamperà come options della select...

Altrimenti i tipi select devono essere legati molti-a-molti con le tabelle che ti interessano e in fase di stampa ti devi fare le query per andarti a pescare i record correlati da mettere nelle options... scomoda come cosa però

Rileggendo però il punto 2, tu hai le scelte col prezzo e le devi associare alle select? fai un molti-a-molti tra le due tabelle e quando stampi una select ti prendi le scelte associate...se lo scenario è semplice probabilmente è più veloce che fare cose più complicate ma "generali"