was ist die beste Implementierung von client-erstellbaren und modifizierbaren web-Formularen in eine relationale Datenbank?

Question

In mehreren web-application-Projekte ich habe ein Teil, fordert der client in der Lage sein, um Ihre eigenen Formen.Stellt sich die Frage, wie die Speicherung Ihrer form, Definitionen, und dann, wie zu speichern Benutzer eingegebenen Werte in die benutzerdefinierten Formen.

Ich habe es gesehen zwei Möglichkeiten:

1. Unter der Annahme, dass der client nur legt fest, wie viele Felder und welche labels sind mit den damit verbundenen Bereichen;wir können kommen, um eine Lösung mit vier Tabellen. FormDefinition, FormFieldDefinition, FormInstances, FormFieldValues.Der Kunde änderungen FormDefinition und FormFieldDefinition, und die web-app verwendet diese Informationen zum Rendern von HTML-web-Formular, auf dem die website-Besucher (Endbenutzer) senden das Formular, in dem Sie eine neue Zeile in FormInstances erstellt und die Werte werden gespeichert, in der FormFieldValues Tabelle.

   Zeilen in FormDefinition definiert die form, D. H. form definition ID = 2, form title = 'Car Registration Form'.Zeilen in FormFieldDefinition definiert Felder eines Formulars in FormDefinition, d.h. field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'.Zeilen in FormInstance ist eine Instanz von jedem Formular ausgefüllt durch einen Benutzer, D. H. definition id = 2, date_entered = '2008-09-24'.Und Zeilen in FormFieldValues sind Einträge durch Benutzer, d.h. field definition = 7, value = 'Tiburon'.

   Leider, es bedeutet, dass der Wert in Spalte FormFieldValues muss ein char-Typ, der die größte Größe möglich, dass Ihr Kunde könnte geben Sie in einem web-Formular...und wenn die form der Definitionen ändern, die Verwaltung, die alten Daten wird zweifelhaft.Aber Benutzer Einträge sind queryable (ich schrieb ein Abfrage das listet die Benutzer-Eingaben eine form gegeben-id, die ähnlich eine weitere pivot-Frage).

2. Eine alternative zur Verwendung von vier Tabellen wäre zu serialisieren Sie die form Definitionen und Benutzer-form-Einträge in XML (oder YAML oder so ähnlich) und speichern Sie als text.Der Vorteil ist, dass die Formen sind menschlich lesbar in der Datenbank.Der Nachteil ist, dass es mehr Applikations-overhead mit Parsen von XML-und die Datenbank wird viel weniger queryable aus SQL-Sicht.

Meine eigentliche Frage ist, was ist das Datenbank-Modell genannt?(So kann ich google dieses problem.) Aber ich würde die Bank auf eine Antwort zu:welche ist die bessere Umsetzung oder gibt es bessere (oder genauso gut) - Implementierungen da draußen?

Answer 1

Was Sie beschreiben, ist oft als "Entity-Attribut-Wert" und manchmal beschrieben als "mixing-Daten und Metadaten." Das heißt, die Namen der Attribute (Felder) werden als Zeichenfolgen gespeichert werden (Daten).

Dies führt zu einer Reihe komplexer Probleme wie zu machen sicher, dass jedes Formular-Instanz enthält den gleichen Satz von Feldern, sicherstellen, dass alle obligatorischen Felder ausgefüllt (das äquivalent von not NULL in eine konventionelle Tabelle).

Sie fragte, wie das beste zu tun dies mit einer relationalen Datenbank.In einer relationalen Datenbank verwenden, sollten Sie die Metadaten für Metadaten.In diesem Fall, es bedeutet die Schaffung einer neuen Tabelle(N) für jede form, und Spalten für die form-Felder.Damit Ihre Formular-definition ist einfach die Metadaten der Tabelle und ein Formular Beispiel ist eine Zeile in dieser Tabelle.Wenn Sie Unterstützung bildet mit mehrwertige Antworten (z.B.Ankreuzfelder), müssen Sie die abhängigen Tabellen zu.

Das mag teuer oder schwer zu skalieren.Wohl wahr.So eine relationale Datenbank möglicherweise nicht das beste Werkzeug für diesen job.Sie erwähnte die Möglichkeit, XML-oder YAML;im Grunde eine Art von strukturierten Datei-format, das Sie definieren können ad-hoc.Definieren Sie eine DTD für jeden Kunden bilden, so dass jede form gesammelt, die validiert werden können.

edit: Wenn Sie wirklich brauchen die Flexibilität der EAV in Ihrer Anwendung, das ist in Ordnung, es sind in der Regel die Umstände rechtfertigen, dass das brechen der Regeln.Nur bewusst sein, die zusätzliche Arbeit, die es kostet, und planen, es in Ihre Entwicklung Zeitplan und wie Sie die Skalierung Ihrer server, um die Last zu bewältigen.Auch die anderen sehen meine Antwort über die EAV auf StackOverflow.

Answer 2

was ist das Datenbank-Modell genannt?

Nicht sicher, was man wirklich zu nennen, aber es ist der gleiche Prozess verwendet in der dynamischen Generierung von Umfragen.Wenn Sie suchen für jede Quelle für die Generierung von Umfrage-Anwendungen, die Sie finden die gleichen Allgemeinen Datenbank-schema sowie ähnliche Methoden.

Schauen Sie auch in den form builder-Websites, wie http://wufoo.com/ oder http://frevvo.com/ für die UI-Ideen (wenn du es web-basiert).

Answer 3

Es gibt eine Dritte option: hier erstellen Sie Tabellen und Spalten hinzufügen, wenn nötig.Es hängt davon ab, wie viele Formen sind erstellt, aber Datenbanken verarbeiten kann leicht eine Menge von Tabellen.Also, wenn ein Benutzer möchte eine form von 'Auto-Registration-Form', Sie fügen eine Tabelle 'CarRegistrationForm'.Für jedes Feld, Sie möchten auf dem Formular können Sie wählen lassen zwischen einigen grundlegenden Arten wie Datum, int und text.Und wenn text ausgewählt ist, haben Sie zu geben eine maximale Länge von pick-Liste, die Ihnen info, wenn das Feld sollte ein varchar oder clob.

Dies funktioniert auf SQL Server, wo Sie können hinzufügen und löschen von Spalten.Für DB2 kann es ein problem sein, da die drop-Spalte ist nicht implementiert.Für die mysql-bin ich mir nicht sicher.

Sie müssen immer noch die Registrierung Ihrer Formen und die Felder, auf der in zwei getrennte Tabellen.

Answer 4

Sie wollen wahrscheinlich Entity-Relationship-Modell

Tatsächlich gibt es GUI-tools zum erstellen von schema-interaktiv von solchen Modellen.