Vom Benutzer erstellte Datenbankstruktur: nicht relationale oder relationale Datenbanken?

Ich empfehle Ihnen dringend, CouchDB dafür auszuprobieren.

1. Sie kommunizieren mit CouchDB über eine einfache REST-API. Mit anderen Worten, es ist " Made des Webs" und nicht nur eine Backend-Datenbank wie MongoDB und andere. CouchDB kann die Formulare tatsächlich bedienen und Einreichungen erhalten, da ein eingebauter Webserver vorhanden ist.
2. Da es sich um einen JSON-Dokumentenspeicher handelt, eignet es sich gut zum Speichern strukturierter Daten. (Formulare und ihre Eingaben sind wirklich Dokumente und es macht mehr Sinn, sie so zu modellieren, IMO.)
3. Sie können problemlos ein JSON-Dokument speichern, das jedes Webformular im selben "Bucket" wie die Formulareinreichungen beschreibt. (CouchDB kann sogar POSTs analysieren und sie in JSON-Dokumente umwandeln, wie Sie es für richtig halten. Beispielsweise ist es einfach, Zeitstempel für Formulareinreichungen zu haben.)
4. Sie könnten eine so genannte "show" -Funktion schreiben, um den HTML-Code jedes Formulars in CouchDB zu generieren. Überprüfen Sie auch "_update" und Validierungsfunktionen.
5. Es hat die Sicherheitsfunktionen, die Sie benötigen würden.
6. Dokumentkonflikte können leicht identifiziert werden. Noch besser, CouchDB bestimmt automatisch eine "gewinnende" Version des Dokuments, aber Sie haben weiterhin Zugriff auf die "verlierenden" Dokumentversionen (bis Sie CouchDB sagen, die Datenbank zu komprimieren, wodurch alte Revisionen entfernt werden.)
   • Was die Eindeutigkeit angeht: Anstatt dass CouchDB eindeutige doc_ids generiert, sollten Sie eine _id zuweisen, die wirklich eine eindeutige Formularübergabe darstellt. Wenn jeder Benutzer nur eine Einreichung pro Formular zulassen soll, verwenden Sie für jedes JSON-Dokument, das aus einer Formularübergabe erstellt wurde, etwas in diese Richtung: submission:user:5:form:a3df2a712

Mit CouchDB können Sie das Problem vermeiden, dynamisch eindeutige Tabellen für jedes Formular zu erstellen, das ein Benutzer erstellen könnte.

Wenn Ihre Daten dem relationalen Modell sehr gut entsprechen, Sie aber einige dynamisch formatierte Daten speichern müssen, die nicht riesig sind, werden Sie wahrscheinlich besser JSON, XML oder Ähnliches in einer Spalte speichern. Obwohl Sie dadurch einige Vorteile der erstklassigen SQL-Typisierung verlieren (Indizierung, Überprüfung von Fremdschlüsseleinschränkungen, Typprüfung usw.), eignet es sich gut zum Speichern dynamisch strukturierter Dokumente, wenn Ihre Abfragen sich nicht um ihre Interna kümmern.

Wenn Sie daran interessiert sind, hauptsächlich relationale Daten mit einem Hauch von JSON / XML / etc. zu speichern, empfehle ich PostgreSQL. PostgreSQL hat einen XML-Datentyp, aber ich empfehle es nicht, da ich XML hasse: P. Niemand hält Sie davon ab, JSON in einem TEXT-Feld zu speichern, aber PostgreSQL wird bald einen JSON-Datentyp mit unterstützenden Funktionen haben. Das hstore Contrib-Modul bietet eine effiziente Möglichkeit zum Speichern von Schlüssel / Wert-Paaren und bietet außerdem Textindex-Unterstützung.

Obwohl das Verschieben von JSON oder ähnlichem in eine SQL-Datenbank-Spalte gegen das relationale Modell gerichtet ist, ist es normalerweise besser, es trotzdem zu tun (wenn es Sinn macht!). Andernfalls müssen Sie das gesamte Schema Ihrer Anwendung der Datenbank erklären, was zu einer Menge SQL- und Datenbank-Mapping-Code führt, der wirklich nichts bewirkt.