Quelle est la meilleure implémentation de formulaires Web créables et modifiables par le client dans une base de données relationnelle?

Question

Dans plusieurs projets d’application Web auxquels je participe, le client demande à pouvoir créer ses propres formulaires. La question se pose de savoir comment stocker leurs définitions de formulaire, puis comment stocker les valeurs saisies par l'utilisateur dans ces formulaires personnalisés.

Je l'ai vu se faire de deux manières:

1. En supposant que le client définisse uniquement le nombre de champs et les étiquettes associées à ces champs; nous pouvons arriver à une solution impliquant quatre tables. FormDefinition , FormFieldDefinition , FormInstances , > FormFieldValues ?? . Le client apporte des modifications à FormDefinition et à FormFieldDefinition , et l'application Web utilise ces informations pour restituer un formulaire Web HTML, sur lequel le visiteur du site Web (utilisateur final) soumettra le formulaire. , dans lequel une nouvelle ligne dans FormInstances est créée et les valeurs sont enregistrées dans la table FormFieldValues ??.

     

   Les lignes dans FormDefinition définissent le formulaire, c'est-à-dire définition de formulaire ID = 2, formulaire title = 'Formulaire d'immatriculation de voiture' . Les lignes dans FormFieldDefinition définissent les champs d'un formulaire sous FormDefinition , c'est-à-dire définition de champ ID = 7, champ label = 'Modèle de voiture', field type = 'varchar (50)' . Les lignes dans FormInstance sont une instance de chaque formulaire rempli par un utilisateur, c'est-à-dire definition id = 2, date_entered = '2008-09-24' . Et les lignes de FormFieldValues ?? sont des entrées de l'utilisateur, c'est-à-dire champ definition = 7, value = 'Tiburon' .

   Malheureusement, cela signifie que la colonne de valeur dans FormFieldValues ?? doit être un type de caractère de la plus grande taille possible que votre client puisse spécifier dans un formulaire Web ... et lorsque les définitions de formulaire changent, gestion des anciennes données devient incertain. Mais les entrées utilisateur sont interrogeables (j'ai écrit une requête rapide qui répertorie les entrées utilisateur auxquelles un identifiant de formulaire a été attribué, à savoir similaire à la autre question pivot ).

2. Une alternative à l'utilisation de quatre tables serait de sérialiser les définitions de formulaire et les entrées de formulaire de l'utilisateur en XML (ou YAML ou quelque chose de similaire) et de le stocker sous forme de texte. L'avantage est que les formulaires sont lisibles par l'homme dans la base de données. L’inconvénient est que l’analyse XML occasionnera plus de temps système aux applications et que la base de données sera beaucoup moins interrogeable du point de vue de SQL.

Ma vraie question est de savoir comment s'appelle ce modèle de base de données. (Je peux donc google ce problème.) Mais je choisirais une réponse: quelle est la meilleure implémentation ou existe-t-il une meilleure (ou tout aussi bonne) mise en oeuvre?

Answer 1

Ce que vous décrivez est souvent appelé "Valeur d'attribut d'entité". et parfois décrit comme "mélangeant données et métadonnées". C'est-à-dire que les noms d'attributs (champs) sont stockés sous forme de chaînes (données).

Cela pose de nombreux problèmes complexes, comme par exemple s’assurer que chaque instance de formulaire contient le même ensemble de champs ou s’assurer que les champs obligatoires sont remplis (l’équivalent de NOT NULL dans un tableau conventionnel).

Vous avez demandé comment faire cela au mieux avec une base de données relationnelle. Dans une base de données relationnelle, vous devez utiliser des métadonnées pour les métadonnées. Dans ce cas, cela signifie créer de nouvelles tables pour chaque formulaire et utiliser des colonnes pour les champs de formulaire. Ainsi, votre définition de formulaire est simplement les métadonnées de la table, et une instance de formulaire correspond à une ligne de cette table. Si vous prenez en charge les formulaires avec des réponses à plusieurs valeurs (par exemple, des cases à cocher), vous avez également besoin de tables dépendantes.

Cela peut sembler coûteux ou difficile à faire évoluer. Probablement vrai. Donc, une base de données relationnelle peut ne pas être le meilleur outil pour ce travail. Vous avez mentionné la possibilité de XML ou YAML; Fondamentalement, un type de format de fichier structuré que vous pouvez définir ad hoc. Vous devez définir une DTD pour le formulaire de chaque client afin que chaque formulaire collecté puisse être validé.

modifier: Si vous avez réellement besoin de la souplesse d'EAV dans votre application, c'est très bien, certaines circonstances justifient le non-respect des règles. Soyez simplement conscient du travail supplémentaire que cela nécessite et planifiez-le dans votre planning de développement et à mesure que votre serveur évolue pour gérer la charge. Voir également une autre réponse à propos de l'EAV . sur StackOverflow.

Answer 2

  

Comment s'appelle ce modèle de base de données?

Vous ne savez pas vraiment comment l'appeler, mais c'est le même processus que celui utilisé pour générer des enquêtes de manière dynamique. Si vous recherchez une source pour générer des applications d'enquête, vous trouverez le même schéma de base de données ainsi que des méthodes similaires.

Recherchez également des sites de création de formulaires, tels que http://wufoo.com/ ou http://frevvo.com/ pour les idées d'interface utilisateur (si vous utilisez le Web).

Answer 3

Il existe une troisième option, où vous créez des tables et ajoutez des colonnes si nécessaire. Cela dépend du nombre de formulaires créés, mais les bases de données peuvent gérer facilement beaucoup de tables. Donc, si un utilisateur veut ajouter un formulaire 'Formulaire d'immatriculation de voiture', vous ajoutez un tableau 'CarRegistrationForm'. Pour chaque champ souhaité sur le formulaire, vous pouvez les laisser choisir entre certains types de base tels que date, int et text. Et lorsque le texte est choisi, ils doivent entrer une longueur maximale dans une liste de sélection, qui vous indique si le champ doit être un varchar ou un clob.

Ceci fonctionne sur SQL Server, où vous pouvez facilement ajouter et supprimer des colonnes. Pour DB2, cela peut poser un problème, car la colonne de dépôt n’est pas implémentée. Pour mysql, je ne suis pas sûr.

Vous devez toujours enregistrer vos formulaires et leurs champs dans deux tableaux distincts.

Answer 4

Vous voulez probablement le modèle relation-entité

Il existe effectivement des outils graphiques permettant de créer un schéma de manière interactive à partir de tels modèles.