Bonjour,
Je me retrouve bloqué sur un autre problème avec Django. Je souhaite représenter un ensemble de formulaire dynamique et effectuer des tris et filtres selon les réponses. Par formulaire dynamique, j’entend qu’on puisse ajouter de nouveaux champs (à partir d’un ensemble de gabarit de champs prédéfinis dans le code) depuis une interface web. Au niveau des performances, ces questionnaires ne concernent qu’environ 300 utilisateurs à chaque fois (ie. pas de jointure avec plus de 300 ligne dans chaque table) et l’interface où l’on manipule l’ensemble des questionnaires n’est utilisée que par une ou deux personnes.
La contrainte de tris/filtres me fait dire que du NoSQL n’est pas bien adapté à ça. Êtes-vous d’accord ?
Je suis donc parti sur une base de données relationnel pour le moment. L’idée que j’ai est de lier la table des questionnaires à une table des champs (qui contiendront un entier représentant le type, un entier représentant l’instance des valeurs du champ et un entier représentant l’instance du champ, ie. les informations qu’il affiche) par une relation many-to-many. On a donc une table qui lie chaque questionnaire à des champs virtuellement séparés en 3 tables..
Il y a quatre cas d’utilisations:
- Récupérer un élement avec tous ses champs.
- Récupérer une liste avec les informations de tous les champs, en filtrant/triant sur les champs.
- Ajouter un questionnaire/réponse/champs à partir d’un gabarit
- Mettre à jour les réponses associées à un champ
Pour les deux dernières, ça ne devrait pas poser de difficultés particulières parce que l’on sait déjà ce que l’on veut. On peut vérifier les données en faisant une requête sur les champs du questionnaire associé. Je vais donc décrire les autres points.
Dans le premier cas, c’est facile en deux requêtes:
- Une première qui récupère la liste de tous les types et réponse des champs de l’élément.
- Une seconde qui récupère la jointure de toutes les tables associées aux différents champs.
Dans le second cas, on peut le faire en deux requêtes avec la méthode suivante:
- Une première qui récupère la liste de tous les champs de l’ensemble des éléments sélectionnés (avec les informations possibles à récupérer) sans doublons.
- Une seconde construite à partir des informations de la première qui fait une jointure des tables des champs.
Est-ce que cela vous paraît raisonnable ? Est-ce que vous connaissez une solution alternative à du SQL pour gérer ce cas-là ? Vous avez peut-être de la littérature à conseiller pour ce genre de travail ?
Merci à vous !