Discussion :

[maddev]

Bonjour tout le monde,

Je viens ici vous consulter pour un problème de conception de base de données qui me chagrine ces temps ci (pardonnez moi si je poste dans la mauvaise section, je n'ai pas trouvé celle appropriée).

Voici mon problème :
Je souhaiterai créer une application qui permet de créer (facilement) puis de remplir des formulaires.
Un petit exemple :
Imaginons par exemple qu'un utilisateur souhaite mettre a disposition un formulaire de demande d'achat pour ses collègues. Il va créer un formulaire et placer les champs "nom" "prenom" "objet_a_acheter" "quantite" "date_d_achat" etc ...

Mon application devra donc stocker les intitulés et types de champs nécessaires au formulaire mais également un espace pour stocker les données saisies dans ces champs.

C'est ici que tout se complique pour moi car plusieurs choix s'offrent a moi ... mais aucun ne me convient vraiment.
1. Mon application pourrait créer une table pour chaque formulaire afin de stocker chaque saisie de données (cela me parait absolument ignoble).
2. Dans mon modèle, je pourrai créer d'origine une table pour chaque type de champs dispo (1 table destinée au varchar, 1 pour les decimal, 1 pour les dates par exemple) et faire des supers jointures. Ce modèle possède un inconveniant : En fonction d'un type de champs, on va chercher une info dans une table différente ... pas très joli (de plus j'ai peur pour le côté performances)
3. Je créer une seule table avec une colonne pour chaque type de champs : varchar, decimal, date ... a chaque saisie, je ne rempli que la colonne qui m'intéresse et laisse les autres à NULL. Ce qui m'embête ici, c'est que pour chaque information saisie, on a 3 champs correspondants en base dont 2 toujours NULL.

Bref ... aucune de mes solutions ne semble convenir. Je suis habitué à travailler avec des modèles de données figés.

Quelqu'un aurait l'idée du siècle pour faire cela proprement ?

[oiseau10]

bonjour,

moi je créerai une table réponse avec :
un champ reponse de type varchar
un champ type_reponse de type entier

Le champ type_reponse contiendra un id de type (1->date, 2->entier, 3->Chaine, ...)
Toutes les réponses sont mises dans reponse, et le champs type permet de retrouver le type. A l'insertion ou à la lecture il faudra caster la réponse en fonction du type (soit directement en SQL, soit avec le langage utilisé pour l'appli)

@+

[CinePhil]

Si je comprends bien votre besoin, vous allez avoir des utilisateurs qui créent des formulaires comprenant un certain nombre de zones de saisie, lesquelles recevront des données qu'il faudra enregistrer.

J'ai mis en gras les entités potentielles et j'ai souligné les associations potentielles.
Il n'y a plus qu'à passer au MCD.

Je vous laisse faire puisque vous savez concevoir des BDD...

Bon courage pour la suite !

[Snipah]

En quelques minutes, je dirai quelque chose de ce gout là :

Une table forumlaire, pour stocker l'identifiant du formulaire et le nom que lui a donné l'utilisateur :
formulaire (id_formulaire, nom_formulaire)

Une table champs, pour décrire chaque champs du formulaire, avec une fk vers formulaire :
champs (id_champs, id_formulaire, nom_champs, type_champs)

Enfin un table reponse, pour stocker les réponses à ce formulaire par les autres utilisateurs :
reponse (id_reponse, id_champs, groupe, valeur)
id_reponse est clé primaire (entier auto incrémenté) parce qu'en général je procède comme ça, mais le couple id_champs/groupe sera necessairement unique et pourrait donc servir de clé primaire.

Une réponse à un formulaire sera le groupe de réponses qui référencent un champs appartenant à ce formulaire (groupe est en quelque sorte le numéro d'une saisie de réponse pour un formulaire).

Pour récupérer l'ensemble des réponses à un formulaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT form.nom_formulaire,
         rep.groupe,
         rep.valeur,
         chs.nom_champs,
         chs.type_champs,
         chs.id_champs
FROM reponse rep
         JOIN champs chs
           ON rep.id_champs = chs.id_champs
         JOIN formulaire form
           ON chs.id_formulaire = form.id_formulaire
WHERE form.nom_formulaire = 'mon formulaire'
ORDER BY rep.groupe,
         chs.id_champs

On peut ensuite afficher par groupe de réponse.
J'espère pas être trop à l'ouest

[maddev]

Si je comprends bien votre besoin, vous allez avoir des utilisateurs qui créent des formulaires comprenant un certain nombre de zones de saisie, lesquelles recevront des données qu'il faudra enregistrer.

Merci à tous pour ces réponses.

Je m'arrête particulièrement sur celle-ci.
Vous comprenez tout a fait le besoin et effectivement à partir de cette phrase on pourrait créer un MCD. Le seul paramètre qui me pose problème est que le type des "données" n'est pas connu au moment de la création de la base de données.

Devrais-je comme d'autres l'ont expliqué créer autant de tables que de type de données potentiels ? Une table destinée à recevoir des varchar, une table destinée à recevoir des dates et une destinée à recevoir des numériques par exemple ?

C'est ce qui paraitrait le + simple. Ce qui me chagrinait un peu c'est qu'en fonction du type de données saisies, on va chercher l'info dans une table différente. Ceci qui ne me paraissait pas super (en même temps je ne trouve pas mieux).

[CinePhil]

Changeons la fin de la phrase...

...lesquelles recevront des données qui sont d'un certain type.

On peut donc utiliser la méthode proposée par oiseau10 et 'caster' la donnée en fonction de son type à la lecture ou par le logiciel applicatif. Si c'est du php, comme c'est un langage faiblement typé, ça ne pose pas de problème de récupérer un résultat numérique issu d'un varchar et de faire des calculs avec.

Par contre, si les données enregistrées grâce aux formulaires doivent ensuite faire l'objet de calculs de masse par le SGBD, il vaudrait mieux enregistrer celles-ci avec leur bon type, surtout si le volume de données deviendra important.

Tout dépend aussi de ce qui sera fait des données par la suite. Si chaque formulaire est destiné à produire des données totalement indépendantes mais volumineuses, il peut être intéressant de créer une table par formulaire comme ça les colonnes correspondant aux champs des formulaires ont forcément le bon type. Mais dans ce ca c'est le logiciel applicatif qui crée les tables à chaque fois qu'un formulaire est créé.

[maddev]

Tout d'abord, merci de prendre le temps de me répondre

Changeons la fin de la phrase...

...lesquelles recevront des données qui sont d'un certain type.

On peut donc utiliser la méthode proposée par oiseau10 et 'caster' la donnée en fonction de son type à la lecture ou par le logiciel applicatif. Si c'est du php, comme c'est un langage faiblement typé, ça ne pose pas de problème de récupérer un résultat numérique issu d'un varchar et de faire des calculs avec.

Par contre, si les données enregistrées grâce aux formulaires doivent ensuite faire l'objet de calculs de masse par le SGBD, il vaudrait mieux enregistrer celles-ci avec leur bon type, surtout si le volume de données deviendra important.

Tout dépend aussi de ce qui sera fait des données par la suite. Si chaque formulaire est destiné à produire des données totalement indépendantes mais volumineuses, il peut être intéressant de créer une table par formulaire comme ça les colonnes correspondant aux champs des formulaires ont forcément le bon type. Mais dans ce ca c'est le logiciel applicatif qui crée les tables à chaque fois qu'un formulaire est créé.

Je compte utiliser les capacités de calculs et de recherche du SGBD. C'est pourquoi je préfèrerais d'avantage que les champs soient correctement typés en base.

La solution qui consiste à créer à la volée une table pour chaque formulaire semble la plus intéressante au point de vue des performances. En revanche, je me demande si c'est raisonnable de donner à mon application les privilèges qui en découlent.
Autre chose qui me fait hésiter : si l'utilisateur décide d'ajouter ou de supprimer un champ au formulaire, cela force à jouer avec des "alter table"

[CinePhil]

Peut-on en savoir un peu plus sur ce projet ?

Sont-ce des formulaires pour une seule entreprise qui devront utiliser des données du système d'information de l'entreprise ?


Concernant les droits de l'application, ce n'est pas vraiment un problème. C'est transparent pour l'utilisateur et c'est le serveur qui travaille.

Je travaille sur une application PHP/MySQL qui utilise une base de métadonnées et qui crée, modifie et supprime elle même des bases et des tables sur le serveur, à chaque fois que l'utilisateur fait certaines opérations. A la limite, l'utilisateur ne s'en rend même pas compte. Il sait qu'il a des bases et des tables sur le serveur mais n'y a accès que via l'application qui gère les droits d'accès des utilisateurs.
Il faut plus considérer ces bases et ces tables comme des répertoires et des fichiers que comme des bases de données relationnelles, ce qu'elles ne sont presque jamais. La seule base de données relationnelle est celle des métadonnées. Elle constitue le coeur du système et n'est alimentée et interrogée que par l'application.

[maddev]

Peut-on en savoir un peu plus sur ce projet ?

Sont-ce des formulaires pour une seule entreprise qui devront utiliser des données du système d'information de l'entreprise ?


Concernant les droits de l'application, ce n'est pas vraiment un problème. C'est transparent pour l'utilisateur et c'est le serveur qui travaille.

Je travaille sur une application PHP/MySQL qui utilise une base de métadonnées et qui crée, modifie et supprime elle même des bases et des tables sur le serveur, à chaque fois que l'utilisateur fait certaines opérations. A la limite, l'utilisateur ne s'en rend même pas compte. Il sait qu'il a des bases et des tables sur le serveur mais n'y a accès que via l'application qui gère les droits d'accès des utilisateurs.
Il faut plus considérer ces bases et ces tables comme des répertoires et des fichiers que comme des bases de données relationnelles, ce qu'elles ne sont presque jamais. La seule base de données relationnelle est celle des métadonnées. Elle constitue le coeur du système et n'est alimentée et interrogée que par l'application.

Je vais décrire un peu le projet :

Le rêve serait de créer une application permettant à une poignée de personnes de créer des applications intranet simples avec un degré de connaissances informatique très limité.

La base utilisateurs est commune (annuaire AD) entre toutes ces mini-applications.

Exemple :
Si le service achat à besoin d'une application pour rassembler les demandes d'achat. On peut créer un formulaire de "demande d'achat". Un utilisateur peut alors saisir une demande et cette requête est envoyée au responsable achat. De son côté, le responsable achat à accès à la demande reçue. Il peut alors effectuer une action (refuser ou accepter l'achat par exemple). Enfin la personne qui fera les commandes aura une liste des achats acceptés.


C'est fou mais rien que la lecture de mon propre exemple me conforte dans l'idée que je devrai créer une table par formulaire.

[chaplin]

Je le fairais en XML, parce que créér un formulaire de saisie de données, sans savoir quoi mettre à l'intérieur, c'est vague.

[maddev]

Je le fairais en XML, parce que créér un formulaire de saisie de données, sans savoir quoi mettre à l'intérieur, c'est vague.

L'XML pourrait être super pratique mais j'ai peur d'être à la ramasse au niveau des performances.
Mon expérience personnelle me fait dire qu'un patron demande en général une petite application simple et qu'au final ... 10 ans après on l'utilise toujours massivement sur une machine "has been" avec des fichiers de données bourrés à craquer.

Je préfèrerais donc travailler un maximum avec le moteur de base qui est certainement plus optimisé que tout ce que je serai capable d'écrire pour utiliser du XML.

[chaplin]

J'ai vu un soft s'appuyant sur XML sur un portable PIII (année 2001) fonctionné convenablement.

EDIT:

Après tout dépend du volume d'enregistrement a traité, dans le cas présent il y avait une centaine de fiches, mais dans lesquels il y avait des formulaires.

[CinePhil]

Exemple :
Si le service achat à besoin d'une application pour rassembler les demandes d'achat. On peut créer un formulaire de "demande d'achat". Un utilisateur peut alors saisir une demande et cette requête est envoyée au responsable achat. De son côté, le responsable achat à accès à la demande reçue. Il peut alors effectuer une action (refuser ou accepter l'achat par exemple). Enfin la personne qui fera les commandes aura une liste des achats acceptés.

Ce n'est peut-être encore qu'un exemple mais... une entreprise assez grande pour avoir un service achat mais pas de logiciel pour gérer ses achats ? En 2009 ?

[maddev]

Ce n'est peut-être encore qu'un exemple mais... une entreprise assez grande pour avoir un service achat mais pas de logiciel pour gérer ses achats ? En 2009 ?

C'est un exemple ... et une réalité
Et oui, il existe encore des entreprise (même de taille conséquente) où l'informatique reste au niveau de la préhistoire. beaucoup de monde ici utilise encore de simples feuilles Excel pour gérer tout et n'importe quoi.