Discussion :

[Eruvatar]

Bonjour,

je me permets de vous demander conseil quand à l'organisation de mes tables afin de les optimiser au mieux. Je sais qu'il n'existe pas qu'une seule manière de procéder, mais j'aimerai avoir l'avis de personne ayant de l'expérience.

Je souhaite créer un systeme ou un utilisateur peut créer des 'actes' avec des comptes rendus associés, c'est a dire qu'a un acte doit etre associé un formulaire avec donc des champs de type text ou textarea ou select et leur intitulé respectifs, sans limite de nombre (ie, un compte-rendu associé à un acte).
Ensuite ces actes pourront etre attribué à des utilisateurs. Il doit etre possible d'ajouter plusieurs actes pour un même utilisateur.

Je pensais donc :
1- Créer une table 'actes' avec 3 colonnes :

• Clé,
• Intitulé de l'acte,
• objet serialisé contenant les champs (ou tout du moins une clé renvoyant vers le type de champ) leurs intitulés, et les valeurs par défauts.

2- Créer une table des contenus du formulaire de chaque acte 3 champs : clé, clé liées a l'utilisateur, clé renvoyant vers la table précédente, valeurs stockées sous la forme d'array serialisé.

Pourquoi ce choix : afin de pouvoir stocker un nombre variable de variable !!!

Inconvénients : est-il judicieux de stocker des objets ou des array dans une table?
Si les textes sont trop gros cela ne risquet-il pas de poser soucis?

Voila, j'espère avoir étét assez clair. Peut être pourrez vous me conseiller sur une méthode moins "bricolage".

Merci

[CinePhil]

un utilisateur peut créer des 'actes'

Immédiatement après ce bout de phrase, la question à se poser pour la compléter est :
Un acte peut-il être créé par plusieurs personnes ?

Selon la réponse on obtient la phrase complète :
"Un utilisateur peut créer des actes et un acte est créé par une seule personne."
Ou bien :
"Un utilisateur peut créer des actes et un acte peut être créé par plusieurs personnes."

Ce genre de phrase s'appelle une règle de gestion et se traduit en morceau de Modèle Conceptuel de Données (MCD) de la méthode Merise (ci-dessous pour la première phrase qui semble plus logique que la seconde) :
Utilisateur -0,n----Créer----1,1- Acte

Pour établir ce morceau de MCD, j'ai analysé la règle de gestion et j'ai :
- mis en gras les entités Utilisateur et Acte;
- souligné l'association Créer ;
- mis en italique ce qui détermine les cardinalités (les chiffres entre parenthèses sur le MCD) : peut et des d'une part, est et une seule d'autre part.

Il découle de ce morceau de schéma les tables suivantes :
Utilisateur (U_Id, U_Nom...)
Acte (A_Id, A_IdCreateur, A_Intitule...)

Ce qui est souligné est l'identifiant (ou clé primaire) de la table.
Ce qui est en italique est la clé étrangère faisant référence à l'identifiant de l'autre table.
Avec cette description de tables, on aura bien un seul utilisateur créateur d'acte par acte et un utilisateur peut créer plusieurs actes.

avec des comptes rendus associés,

Un acte peut faire l'objet de plusieurs comptes-rendus et un compte-rendu se rapporte à un seul acte ?

MCD :
Compte-rendu -1,1----Se Rapporter----0,n- Acte

c'est a dire qu'a un acte doit etre associé un formulaire avec donc des champs de type text ou textarea ou select et leur intitulé respectifs, sans limite de nombre (ie, un compte-rendu associé à un acte).
Ensuite ces actes pourront etre attribué à des utilisateurs. Il doit etre possible d'ajouter plusieurs actes pour un même utilisateur.

Ca c'est du traitement, à voir après la modélisation des données.

Je pensais donc :
1- Créer une table 'actes' avec 3 colonnes :

• Clé,
• Intitulé de l'acte,

Oui.

• objet serialisé contenant les champs (ou tout du moins une clé renvoyant vers le type de champ) leurs intitulés, et les valeurs par défauts.

Qu'entendez-vous par "objet sérialisé" ?
Une colonne contenant plusieurs champs (plusieurs colonnes ?), ce n'est pas bon.

2- Créer une table des contenus du formulaire de chaque acte 3 champs : clé, clé liées a l'utilisateur, clé renvoyant vers la table précédente, valeurs stockées sous la forme d'array serialisé.

Euh... là je ne comprends plus !
J'ai l'impression que vous mélangez la modélisation des données et les traitements qui seront faits sur les données.
Je vous invite à lire le tutoriel de SQLPro sur la modélisation Merise, dont j'ai donné le lien plus haut.

Définissez votre besoin à l'aide de règles de gestion comme celle que j'ai écrite ci-dessus puis transformez-les en morceaux de MCD que vous raccorderez.
Servez-vous pour cela d'un logiciel de modélisation tel que Power AMC (payant) ou Open ModelSphere (gratuit) ou encore MySQL Workbench (gratuit ou payant selon version) qui ne vous donnera pas exactement un MCD mais un modèle Entité/Relation. Si vous optez pour ce dernier logiciel et que vous n'avez jamais modélisé, je vous conseille de faire d'abord un MCD à la main sur papier puis de le traduire en MLD directement à l'aide de MySQL Workbench.

Bon courage !

[Eruvatar]

Merci beaucoup pour cette réponse exhaustive, je prends connaissance de la méthode Merise tout de suite afin de combler ces trop grosses lacunes.

Bonne journée à vous, et encore merci.

[fsmrel]

Concernant l'apprentissage de MERISE, n'hésitez pas à étudier « Parlez-vous Merise ? », ouvrage mis gracieusement à la disposition de tous par un orfèvre en la matière, Michel Diviné.