Forum d'entraide PHPFrance

Bonjour,

je suis sur la création d 'un site de devis pour lequel je vais avoir une table projet pour chaque activité sachant que j'ai environ 380 activités.
Cela me parait énorme de faire 380 tables activité_projet . Je n'ai pas l'habitude de faire des sites pour lesquels il y autant de tables je voulais savoir si cela était normal ou est-ce qu'il y a quelque chose à quoi je n'ai pas pensé...
J'ai pensé faire une seule table projet dans laquelle j'enregistrerai les différents champs des différents formulaires correspondant aux différentes activités séparer d'une virgule ou point virgule (avec la fonction explode).
Dites moi si ça se fais ou pas du tout.

merci pour votre lecture.

Tte les réponses sont les bien venues merci !

Bonjour.

C'est un peu délicat de répondre comme ça sans plus d'info, mais a priori une table par activité, c'est foireux.
Pareil, a priori enregistrer plusieurs champs de formulaire dans un seul champ, c'est foireux.

Il faudrait que tu fasses une analyse de ton projet, et modélises ta base.

bonjour lol

ok tout est foireux donc là je suis encore moins avancé qu'avant.

en fait pour chaque activité le formulaire projet change ( pas les même champs) donc je suis obliger de faire une activité_table projet qui corresponde à chaque activité comme tu dis c'est foireux .

j ai pensé faire une classe mère projet et ses classes filles activité1_projet, activité2_projet mais là encore pour la base de donnée comment je fais?

bonjour lol

ok tout est foireux donc là je suis encore moins avancé qu'avant.

en fait pour chaque activité le formulaire projet change ( pas les même champs) donc je suis obliger de faire une activité_table projet qui corresponde à chaque activité comme tu dis c'est foireux .

Qu'est-ce que c'est qune "activité" ?
Qu'est-ce que c'est qu'un "projet" ?
Que vient faire un formulaire dans la modélisation de ta BDD ?

Tu peux détailler un peu ?
- Relation entre Activité et Projet ?
- Quels peuvent être les champs de formulaire ?

bonjour lol

ok tout est foireux donc là je suis encore moins avancé qu'avant.

en fait pour chaque activité le formulaire projet change ( pas les même champs) donc je suis obliger de faire une activité_table projet qui corresponde à chaque activité comme tu dis c'est foireux .

Qu'est-ce que c'est qune "activité" ?
Qu'est-ce que c'est qu'un "projet" ?
Que vient faire un formulaire dans la modélisation de ta BDD ?

Tu peux détailler un peu ?
- Relation entre Activité et Projet ?
- Quels peuvent être les champs de formulaire ?

alors c'est un site de devis, le client vient remplis le formulaire de description de projet, pour l'activité climatisation c'est par exemple
nombre de pièce à climatiser:
supérficie :
caractérisqtique : etc..
et pour l'activité soutient scolaire par exemple
matière :
classe:
fréquence:
voilà est ce que tu vois?

alors c'est un site de devis, le client vient remplis le formulaire de description de projet, pour l'activité climatisation c'est par exemple
nombre de pièce à climatiser:
supérficie :
caractérisqtique : etc..
et pour l'activité soutient scolaire par exemple
matière :
classe:
fréquence:
voilà est ce que tu vois?

Un exemple vite fait à prendre pour ce qu'il vaut donc - je ne prétends pas non plus être Ze spécialiste, hein...
Notation : TABLE (clé_primaire *, clé_etrangère_table_origine #)

ACTIVITES ( id_activite *, nom, divers)
FORMULAIRES (id_champ *, id_activite #, nom_champ, type_champ)

Pour créer ton formulaire en fonction de l' ID de l'activité tu récupères tous les champs de l'activité :

SELECT nom_champ, type_champ FROM FORMULAIRES where id_activite = ID

Evidemment, ça t'oblige à avoir une présentation standardisée au max, et du coup en pratique ce n'est pas forcément ce qu'il y a de mieux.

Tu peux aussi avoir ta table ACTIVITES ( id_activite *, nom, formulaire, divers), avec ton champ formulaire qui contient le code du formulaire.

En fait, ça va dépendre (entre autres) de ce que tu veux faire de ton formulaire, de l'usage que tu fais des champs du formulaire, etc.

alors c'est un site de devis, le client vient remplis le formulaire de description de projet, pour l'activité climatisation c'est par exemple
nombre de pièce à climatiser:
supérficie :
caractérisqtique : etc..
et pour l'activité soutient scolaire par exemple
matière :
classe:
fréquence:
voilà est ce que tu vois?

Un exemple vite fait à prendre pour ce qu'il vaut donc - je ne prétends pas non plus être Ze spécialiste, hein...
Notation : TABLE (clé_primaire *, clé_etrangère_table_origine #)

ACTIVITES ( id_activite *, nom, divers)
FORMULAIRES (id_champ *, id_activite #, nom_champ, type_champ)

Pour créer ton formulaire en fonction de l' ID de l'activité tu récupères tous les champs de l'activité :

SELECT nom_champ, type_champ FROM FORMULAIRES where id_activite = ID

Evidemment, ça t'oblige à avoir une présentation standardisée au max, et du coup en pratique ce n'est pas forcément ce qu'il y a de mieux.

Tu peux aussi avoir ta table ACTIVITES ( id_activite *, nom, formulaire, divers), avec ton champ formulaire qui contient le code du formulaire.

En fait, ça va dépendre (entre autres) de ce que tu veux faire de ton formulaire, de l'usage que tu fais des champs du formulaire, etc.

ok merci pour ta réponse, c'est très intéressant ce que tu me propose pour une création dynamique des formulaires mais moi moi mon souci c'étais pour l'enregistrement du cou p le problème n'est pas réglé? ou alors il y a un truk que j' ai pas saisi. puisque ok les champs vont être créer en fonction de l'id de l'activité , mais du coup je reviens à mon problème de une table pour chaque activité:
table projet_climatisation( id_projet,id_client, ...) et le reste? le reste c'est donc les champs qui corresponde à chaque activité? (il y a 380 activité rappelons le)
si je fais
projet_climatisation( id_projet,id_client, projet) avec le champs projet qui contient ttes les valeur entrée par l'utilisateur dans les champ du formulaire séparer par une virgule (tjrs avec explode lol je lache pas l'affaire) du coup si je veux extraire a présent les données pour les afficher je ferais une requête qui va chercher le nom des champs dans la table ACTIVITE(celle que tu ma donné plus haut) et la valeur que j'irais chercher dans le champs projet de la table projet_climatisation pffiou c'est tiré par les cheveu jpense..

ok merci pour ta réponse, c'est très intéressant ce que tu me propose pour une création dynamique des formulaires mais moi moi mon souci c'étais pour l'enregistrement du cou p le problème n'est pas réglé?

si je fais
projet_climatisation( id_projet,id_client, projet) avec le champs projet qui contient ttes les valeur entrée par l'utilisateur dans les champ du formulaire séparer par une virgule (tjrs avec explode lol je lache pas l'affaire) du coup si je veux extraire a présent les données pour les afficher je ferais une requête qui va chercher le nom des champs dans la table ACTIVITE(celle que tu ma donné plus haut) et la valeur que j'irais chercher dans le champs projet de la table projet_climatisation pffiou c'est tiré par les cheveu jpense..

En fait, ça va dépendre (entre autres) de ce que tu veux faire de ton formulaire, de l'usage que tu fais des champs du formulaire, etc.

Pour le explode(), c'est vrai que, à première vue, ça peut te simplifier les choses.
Mais tu risques d'avoir des problèmes rapidement si tu as besoin de faire des traitements un peu poussés.
Essaye d'imaginer, par exemple, comment faire pour récupérer les "activités" de soutien scolaire pour les CM1

Je me répète, mais ça va dépendre de ce que tu veux faire...
- Est-ce que tu veux avoir des projets complètement indépents (auquel cas tu peux envisager les 380 tables), ou est-ce que tu veux (par exemple) pouvoir trouver tous les projets envoyés par M. Dupont, qu'il s'agisse de soutien ou de climatisation ?
- Prévois-tu des traitements en fonction des "champs" de ces projets (si oui, évite le explode() )?
- Etc.

Bref, réflechis bien à ce que tu veux, maintenant et dans le futur, analyse tes besoins, en particulier ce que tu veux faire de tes données (pourquoi les stocker, quels traitements, etc.)
A partir de là, tu peux faire le schéma de ta BDD.
On ne peut pas te donner une organisation optimale sans avoir tous les tenants et aboutissants de ton projet...

ce sont des projets différents ensuite pour le ce que je veux en faire ensuite c est juste récupérer par exemple le nombre de devis fais par mr intel du coup sa pause pas de probleme car une table projet contiendrai activite_projet(id projet, idclient, ...) et non je ne pense pas avoir a faire de traitement poussé de recherche sur "cm1" et quand bien même sa serait tjrs possible avec les fonction de recherche sur les chaine de caractères enfin je pense que je vais faire les 380 tables c est plus propre même si c est plus long..
Pour les formulaire j ai un corp qui est tjrs le meme puis les bout de formulaire spécifique dans des fichier que j includes en fonction ..
enfin voilà..
merci pour ton aide et tes propositions.

Sinon une table devis :

-id
-id_activite
- nom
- telephone
- ...
- champ_specifique

Dans champ_specifique tu serialize() les données, en espérant ne pas avoir à faire de recherche dedans ...

Puis tu crées une table activite, avec id, et nom activité.

Sinon, pourquoi pas 380 tables, mais pense bien à modéliser les choses, et tu pourras même avec juste quelques lignes de php générer les qq tables ... Pour ce genre de projets, un seul maître mot : Modélisation

L'idée est sûrement saugrenu mais en repartant de tous ce qu'il y avant ne serait il pas possible de faire :
- 1 table devis (id *, idclient #, idactvite # etc)
- 1 table client (idclient *, nom etc)
- 1 table activité (idactivite *, nom, description, etc)
- 1 table champsformulaireactivite ( id *, nom, type, id activité etc)
- 1 table valeurschampformulaire (id *, idchampformulaire, valeur)

Oui oui ca fait 5 tables, mais :
ça permet de récupérer simplement les activités, les clients, les devis, les devis d'un client, d'afficher les champs que l'on souhaite pour une activité (bon faut les rentrer au départ dans la table) et cela avec une seule classe qui affiche un formulaire dynamique en fonction de l'activité choisit et d'enregistrer la valeur de tous les champs (dans la dernière table) quelque soit son type

Mieux encore il est possible de modifier un formulaire (en ajoutant, modifiant ou supprimant des champs simplement, attention au delete car il faut penser a supprimer les champs correspondants dans la table des valeurs, ca se fait simplement avec les contraintes de clefs étrangères)

Au final je dirais que c'est tout benef meme si le code est ploi plus complexe ?

Je me goure peut etre mais je trouve ca plus maintenable que 380 (plus dans l'avenir ?) table ?

@+