Bonjour
Je viens vers vous car j'aimerais avoir un conseil de conception sur une partie de mon système de données. Je vais essayer de présenter la chose dans sa globalité, mais je pense que cela va être compliqué.
Je programme un site Internet qui est en fait un système de sites. J'ai une page et une seule page qui répond à tous mes DNS. Grâce au MemberShip du FrameWork 2.0 je gère l'accès aux sites par l'URL qui devient une "application" dans le MemberShip. Ensuite, le code principal de ma page plonge dans la base de donnée pour trouver les modules pour remplir la page voulue dans le site voulu. Puis chaque module dispose de son sous système de données pour se remplir.
Ma préoccupation se situe sur le stockage des données de l'utilisateur enregistré sur un site. Le MemberShip me donne la possibilité de gérer tout ce qui concerne la connexion et la gestion des droits. Mais j'ai besoins de gérer d'autres infos. Par exemple, sur un site associatif j'ai besoins de gérer l'adresse mail (c'est pris en charge par le MemberShip, au besoins ça sert d'identifiant) mais également le nom et le prénom, et c'est tout. Pour mon site de rencontre, là j'ai besoins de gérer beaucoup plus de chose : ville de résidence, date de naissance, loisirs, taille, poids et description. Vous l'aurez compris, plusieurs types de données à stocker. Et surtout, contrairement au premier site, il faut que je fasse des requêtes et que je stocke les critères de recherche.
Enfin, j'ai besoins de construire des formulaires pour gérer toutes ces données au niveau utilisateur. J'ai fabriqué un module qui gère les formulaires en les nourrisant à partir d'une table qui contient la description des formulaires. J'aimerais beaucoup garder ce principe car il est trés souple et me permet de faire autant de formulaire que je veux sur autant de site que je veux.
Mais vient ensuite la problématique de stockage des données. Je suis parti sur une idée de stockage vertical. Donc, en fonction du descriptif du champ de formulaire je sais quel type de données je vais stocker et je rentre dans ma table un identifiant de donnée, un identifiant d'utilisateur, le nom de la donnée et sa valeur. Mais j'ai de gros problème pour faire des requêtes là dessus. Et ensuite je rencontre des soucis pour gérer les données qui ne sont pas gérée par l'utilisateur tel que la période d'abonnement.
Une autre diée (que je n'ai pas mis en oeuvre, mais qui m'a paru pas trop mal) était de rester sur un stockage Horizontal et prévoir une quantité de champ de chaque type de donnée :
- Identifiant de la ligne
- Identifiant de l'utilisateur
- Champ Numérique 1
- Champ Numérique 2
- Champ Numérique x
- Champ date 1
- Champ date 2
- Champ Date x
- Champ text 1
- Champ text 2
- Champ text x
Ensuite, je mets une table dérivée pour le stockage des listes de choix. Et je récupère mon module de fabrication de champ en logant le nom du champ qui va recevoir la donnée dans la description du champ de formulaire. Mais là, j'atteins des limites (alors que pas dans l'autre cas). Par exemple, si j'ai 5 champs numériques, mais que pour un site donné j'ai besoins de 6 champs : je suis bloqué. Par contre, je n'ai plus de problème pour faire mes requêtes et stocker mes critères de recherche et gérer les abonnements.
Voilà, je crois avoir tout présenté. Alors ma question est assez simple dans son expression : quelle solution vous parait la meilleure : la première, la seconde ou une autre (dans ce cas, la quelle)?
Je suis ouvert à toute proposition.
Partager