Optimiser les modèles de données de l’entreprise
Une des principales demandes de mes responsables étaient l'amélioration de la base de données, car celle de D'MatDoc, en plus d'être assez complexe à lire, laissait peu de place à de potentielles améliorations.
De plus, mon tuteur souhaitait intégrer la sérialisation des formulaires, réduisant leur contenu à un fichier JSON rattaché au formulaire dans la base de données, ainsi que le multibase, fracturant ainsi la base en 2. Après avoir analysé les besoins du site ainsi que la base existante, j'ai proposé une nouvelle version ayant pour but de simplifier au maximum la base tout en intégrant les demandes de mon responsable en expliquant mes choix. J'en ai également profité pour harmoniser la nomenclature utilisée.
Cette nouvelle version est séparée en deux morceaux distincts: la gestion des utilisateurs à gauche, et la gestion des formulaires à droite. Ce changement radical de base de données étant prévu dès le début, il m'a permis d'établir précisément comment exploiter la base de données pour le bon fonctionnement du site. Je vais revenir sur l'utilisation de cette séparation dans la partie suivante.
Assurer la confidentialité des données (intégrité et sécurité)
La séparation en deux parties de la base a comme but principal d'éviter d'accéder à tout les formulaires d'un coup. Pour cela, lorsqu'on se connecte au site, il n'a accès qu'à la base utilisateur, commune à toutes les sessions, puisqu'on doit identifier l'utilisateur. Une fois identifié, on va se connecter à la base de données de sa société, et si elle n'existe pas encore on la créée. Cette base couvre uniquement la portion formulaire du site. Ainsi quand on effectue une recherche de formulaires selon un type, on ne parcourt que les formulaires appartenant à la société. Un processus similaire a lieu pour une connexion au site pour répondre à un formulaire, sauf que cette fois, l'utilisateur n'a pas besoin de se connecter, car le QR code permettant la redirection précise la société du formulaire indique à quelle base de formulaire le site doit être connecté. Grâce à ce système, il est impossible d'accéder à une page autre que la connexion ou la réponse d'un dit formulaire, car sinon l'absence de connexion à une base de formulaire bloque le fonctionnement du site. Cela permet aussi de s'assurer que seuls les utilisateurs autorisés peuvent modifier des éléments dans la base.
Organiser la restitution de données à travers la programmation et la visualisation
Lorsque l'utilisateur accède à un type de formulaire, le site va lui faire une liste des formulaires de ce type présent dans la base de la société, il a alors la possiblité de trier par catégorie pour faciliter sa recherche, ainsi qu'ajouter, éditer, supprimer ou visualiser les réponses d'un formulaire; il peut également faire les trois premières options pour les catégories.
La suppression va juste demander la confirmation avant de supprimer le formulaire avec toutes ses réponses, tandis qu'ajouter un formulaire va ouvrir la page édition sous son mode ajout (donc sans avoir charger le contenu d'un formulaire). Dans le cas d'une éditon, le bouton va récupérer l'identifiant du formulaire stocké sur la ligne ou il est situé pour charger son contenu dans la page édition. Le même fonctionnement s'applique pour la visualisation des réponses. Si la page visualisation des réponses ne fait que lire le contenu du formulaire, l'édition, comme son nom l'indique, fait plus que ça. Après avoir chargé (si en mode édition) ou non, l'intégralité de ce qui se passe sur la page n'est pas sauvegardé tant qu'on ne clique pas sur le bouton enregistrer. Si le formulaire est déjà dans la base, on sérialise le nouveau contenu et on modifie l'élément dans la base en prennant en comptes les autres informations modifiées. En cas d'ajout, la page récupère l'identifiant attribué automatiquement au formulaire, afin que les enregistrements suivants ne fasse que modifier ce formulaire, puisqu'on ne quitte pas la page quand on sauvegarde.
Manipuler des données hétérogènes
Comme mentionné plus haut, le choix a été fait de sérialiser les questions des formulaires. Actuellement, on a trois type de formulaire qui utilisent tous les trois un tableau d'élément d'une classe CChamp pour stocker les informations de chaque question. Le tableau est ensuite sérialisé au format JSON pour être stocké dans la base de données.
Un des buts de cette décision est de pouvoir couvrir tous les types de champs sans devoir faire une table dans la base par type de champ. Comme on le voit ici, chaque type de question est sauvegardé avec toutes les informations requises. De plus, si on souhaite ajouter des types de formulaires avec des structures différentes dans le futur, on pourra simplement sérialiser le contenu pour les traiter comme un autre type de formulaire, l'élément F_Type dans la table Formulaire servant à faire la différence. Cependant cela a également eu comme conséquence de devoir sérialiser les réponses avec leur propre classe pour stocker les réponses, mais à l'image du contenu d'un questionnaire, on peut toujours créer de nouvelles classes pour stocker les réponses selon les besoins du type de formulaire.
Petit détail, mais le choix d'utiliser un UUID à 256 bits ici aussi a pour but d'éviter des problèmes de nomination des colonnes en visualisation des réponses, ainsi que pour réassigner les réponses plus facilements aux champs en évitant les problèmes de doublons, cela permet aussi d'avoir des champs qui portent la même question/libellé.