qual è la migliore implementazione di moduli web creabili e modificabili in un database relazionale?

Question

In diversi progetti di applicazioni Web di cui ho fatto parte, il cliente chiede di essere in grado di creare i propri moduli. Si pone la domanda su come archiviare le definizioni dei moduli e quindi su come archiviare i valori immessi dall'utente in tali moduli personalizzati.

L'ho visto in due modi:

1. Supponendo che il client definisca solo quanti campi e quali etichette sono associate a tali campi; possiamo arrivare a una soluzione che coinvolge quattro tabelle. FormDefinition , FormFieldDefinition , FormInstances , FormFieldValues ?? . Il client apporta le modifiche a FormDefinition e FormFieldDefinition e l'app Web utilizza tali informazioni per eseguire il rendering di un modulo Web HTML, sul quale il visitatore del sito Web (utente finale) invierà il modulo , in cui viene creata una nuova riga in FormInstances e i valori vengono salvati nella tabella FormFieldValues ??.

     

   Righe in FormDefinition definisce il modulo, ovvero ID definizione modulo = 2, titolo modulo = 'Modulo di registrazione auto' . Le righe in FormFieldDefinition definisce i campi di un modulo in FormDefinition , ovvero ID definizione campo = 7, etichetta campo = 'Modello auto', field type = 'varchar (50)' . Righe in FormInstance è un'istanza di ciascun modulo compilato da un utente, ovvero definition id = 2, date_entered = '2008-09-24' . E le righe in FormFieldValues sono voci dell'utente, ovvero field definition = 7, value = 'Tiburon' .

   Sfortunatamente, significa che la colonna del valore in FormFieldValues ?? deve essere un tipo di carattere della dimensione massima possibile che il client potrebbe specificare in un modulo Web ... e quando cambiano le definizioni del modulo, gestendo i vecchi dati diventa incerto. Ma le voci degli utenti sono interrogabili (ho scritto una query rapida che elenca le voci degli utenti con un ID modulo, che è simile a un'altra domanda pivot ).

2. Un'alternativa all'utilizzo di quattro tabelle sarebbe quella di serializzare le definizioni dei moduli e le voci dei moduli dell'utente in XML (o YAML o qualcosa di simile) e archiviarlo come testo. Il lato positivo è che i moduli sono leggibili dall'uomo nel database. Il rovescio della medaglia è che ci sarà un sovraccarico di applicazioni con l'analisi dell'XML e il database diventerà molto meno interrogabile da un punto di vista SQL.

La mia vera domanda è: come si chiama questo modello di database? (Quindi posso cercare su Google questo problema.) Ma mi accontenterei di una risposta a: qual è l'implementazione migliore o ci sono implementazioni migliori (o altrettanto buone) là fuori?

Answer 1

Quello che stai descrivendo viene spesso chiamato " Entity-Attribute-Value, " e talvolta descritto come "miscelazione di dati e metadati". Cioè, i nomi degli attributi (campi) sono memorizzati come stringhe (dati).

Questo porta a una serie di problemi complessi come assicurarsi che ogni istanza del modulo includa lo stesso insieme di campi o assicurarsi che i campi obbligatori siano compilati (l'equivalente di NOT NULL in una tabella convenzionale).

Hai chiesto il modo migliore per farlo con un database relazionale. In un database relazionale, è necessario utilizzare i metadati per i metadati. In questo caso, significa creare nuove tabelle per ciascun modulo e utilizzare le colonne per i campi del modulo. Quindi la definizione del modulo è semplicemente i metadati della tabella e un'istanza del modulo è una riga in quella tabella. Se supporti moduli con risposte a più valori (ad esempio caselle di controllo), devi disporre anche di tabelle dipendenti.

Potrebbe sembrare costoso o difficile da ridimensionare. Probabilmente vero. Quindi un database relazionale potrebbe non essere lo strumento migliore per questo lavoro. Hai citato la possibilità di XML o YAML; fondamentalmente una sorta di formato di file strutturato che è possibile definire ad hoc. È necessario definire un DTD per il modulo di ciascun cliente, in modo che ogni modulo raccolto possa essere convalidato.

modifica: Se hai davvero bisogno della flessibilità di EAV nella tua applicazione, va bene, di solito ci sono circostanze che giustificano la violazione delle regole. Basta essere consapevoli del lavoro aggiuntivo necessario e pianificarlo nel programma di sviluppo e mentre si ridimensiona il server per gestire il carico. Vedi anche un'altra mia risposta sull'EAV su StackOverflow.

Answer 2

  

come si chiama questo modello di database?

Non sono sicuro di come chiamarlo, ma è lo stesso processo utilizzato per generare dinamicamente sondaggi. Se cerchi una fonte per generare applicazioni di indagine troverai lo stesso schema generale del database e metodi simili.

Cerca anche nei siti dei costruttori di moduli, come http://wufoo.com/ o http://frevvo.com/ per le idee sull'interfaccia utente (se lo stai realizzando in base al Web).

Answer 3

Esiste una terza opzione, in cui è possibile creare tabelle e aggiungere colonne, se necessario. Dipende da quanti moduli vengono creati, ma i database possono gestire facilmente molte tabelle. Pertanto, se un utente desidera aggiungere un modulo "Modulo di registrazione auto", aggiungi una tabella "CarRegistrationForm". Per ogni campo che desiderano nel modulo, puoi lasciarli scegliere tra alcuni tipi di base come data, int e testo. E quando viene scelto il testo, devono inserire una lunghezza massima da un elenco di selezione, che fornisce informazioni se il campo deve essere un varchar o un clob.

Funziona su SQL Server, dove puoi facilmente aggiungere e rilasciare colonne. Per DB2 può essere un problema, perché la colonna di rilascio non è implementata. Per mysql non ne sono sicuro.

Devi ancora registrare i tuoi moduli e i campi su di esso in due tabelle separate.

Answer 4

Probabilmente vuoi Modello di entità-relazione

Esistono infatti strumenti della GUI per creare schemi interattivamente da tali modelli.