Structure de base de données créée par l'utilisateur: bases de données non relationnelles ou relationnelles?

Si vos données conviennent assez bien au modèle relationnel, mais vous devez stocker des données formatées de manière dynamique qui n'est pas énorme, alors vous serez probablement mieux en train de stocker JSON, XML ou similaire dans une colonne. Bien que vous perdiez des avantages de la saisie de SQL de première classe en faisant cela (indexation, vérification de la contrainte de clé étrangère, vérification de type, etc.), il est bon de stocker des documents structurés de manière dynamique lorsque vos requêtes ne se soucient pas beaucoup de leurs internes. < / p>

Si vous êtes intéressé à stocker principalement des données relationnelles avec une touche JSON / XML / etc., je vous recommande de regarder PostgreSQL. PostgreSQL a un type de données XML, mais je ne vous recommande pas de l'utiliser depuis que je déteste XML: p. Personne ne vous empêche de stocker JSON dans un champ de texte, mais PostgreSQL aura bientôt un type de données JSON avec des fonctions de support. HSTORE Le module de contributions offre un moyen efficace de stocker des paires de clé / valeur et fournit également un support d'index de texte complet.

Bien que pousse JSON ou similaire dans une colonne de base de données SQL vole face au modèle relationnel, vous êtes habituellement mieux de le faire quand même (quand cela a du sens!). Sinon, vous devez expliquer l'ensemble du schéma de votre application à la base de données, ce qui aboutit à beaucoup de code de cartographie SQL et de base de données qui ne fait vraiment rien.

Je vous recommande vivement de consulter Couchdb pour cela.

1. Vous communiquez avec Couchdb à l'aide d'une API de repos simple. En d'autres termes, il est "< fait du web" plutôt que simplement d'être un dB backend comme MongoDB et d'autres. CouchDB peut réellement servir les formulaires et recevoir des soumissions depuis qu'un serveur Web intégré.
2. Être un magasin de documents JSON Il convient parfaitement à la conservation des données structurées à la schémas. (Les formulaires et leurs soumissions sont vraiment des documents et il est plus logique de les modéliser de cette façon, Imo.)
3. Vous pouvez facilement stocker un document JSON qui décrit chaque formulaire Web dans le même "godet" comme soumissions de formulaire. (COUCHDB peut même analyser les postes de former et les transformer en documents JSON, mais vous voyez l'ajustement. L'avoir automatiquement des soumissions de formulaire d'horodatage, par exemple, est simple.)
4. Vous pouvez écrire ce que l'on appelle une fonction "_Show" pour générer le code HTML de chaque formulaire dans Couchdb. Découvrez également les fonctions "_Update" et de validation.
5. Il possède les fonctionnalités de sécurité dont vous auriez besoin.
6. Les conflits de documents peuvent être identifiés facilement. Encore meilleur, Couchdb détermine automatiquement une version "gagnante" du document, mais vous continuerez d'avoir accès aux versions de documents "Perdre" (jusqu'à ce que vous disiez que CouchDB compacte la base de données, qui supprime les anciennes révisions.)
   • En ce qui concerne l'unicité: au lieu d'avoir CouchDB générer un document DOC _ID unique, vous voudrez attribuer un IDID qui représente vraiment une soumission de formulaire unique. Si chaque utilisateur est autorisé uniquement une soumission par formulaire, utilisez quelque chose sur ces lignes pour chaque document JSON créé à partir d'une soumission de formulaire: Soumission: Utilisateur: 5: Formulaire: A3DF2A712

     Utilisation de CouchDB Vous pouvez éviter la douleur de créer de manière dynamique des tables uniques pour chaque formulaire qu'un utilisateur pourrait créer.