Discussion :

[zooffy]

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.

[elsuket]

Bonjour,

Je te propose le schéma suivant :



Les entités estAbonneRencontre et estAbonneAssociatif héritent de l'entité estAbonne.
L'entité Abonnement est dénormalisée
Et bien sûr il manque des colonnes
Qu'en penses-tu ?

Tu peux aussi poser ta question ici

@++

[zooffy]

Merci pour ton aide.

Je vais réfléchir à ta proposition mais je vois déjà quelques souci :
- le mail est géré dans une table du MemberShip
- le fait d'avoir une table site de Rencontre et une table site associatif implique une table par site, et c'est ce genre de chose que je cherche à éviter.

En fait, faudrait déjà partir du modèle imposé par le MemberShip, mais je n'ai pas d'outil pour le présenter. Est ce que SQL 2005 Express propose un outil de présentation comme celui que tu as utilisé ?

Je vais faire un copier coller de ma question sur le forum que tu propose.

[elsuket]

Quand tu es sous Management Studio, chaque node de base de données comporte une node "Schémas de base de données".
En cliquant droit dessus, tu peux choisir "Nouveau schéma de base de données", mais cela reste très proche du MPD ...

@+

[zooffy]

Ok, Merci pour cette astuce.

Bon, ben dés que ma machine est réparée, je fais ça.

(euh, oui, parce que là, j'ai ma machine est en carafe faut changer la carte mère, donc je garde le contact avec un vieil HP Celeron, histoire d'avoir de l'internet)

Et donc, je profite de ce temps pour faire un peu de conception.