je suis sur la création d 'un site de devis pour lequel je vais avoir une table activité_projet pour chaque activité sachant que j'ai environ 380 activités. (le formulaire n'est jamais le même pour chaque activité donc la table aussi..)
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.
Une table par activités, c'est mal conçu.
Des champs contenant des trucs séparées par des points virgules que tu traites avec explode ou autre, c'est mal conçu...
Je propose que tu nous explique en détails ce que tu dois stocker comme données, qu'on puisse t'aiguiller sur une meilleure solution.
je suis ravie de trouver des réponses lol
alors, c 'est un site de devis , il y a des secteurs d'activités ex: travaux ou encore service à la personne
dessous ya des sous-catégorie:
Devis tavaux > climatisation
Service à la personne > soutien scolaire
le client vient et rempli le formulaire qui contient les civilité donc la j'ai une table clients normal qui contient les civilité (nom prenom gnagna...)
ensuite la partie du formulaire qui contient la description du projet
les champ sont par exemple:
nombre de pièce a climatiser:
supérficie:
délais:
pour cours de soutient c'est par exemple:
nombre d'heures:
classe de l'élève:
fréquence:
et donc c'est la le problème je ne peu pas créer une salle table projet vu que les champ ne sont pas les même selon les activités donc je me suis posé la question est ce normal de faire une table pour chaque activité?
problème de conception je veux bien mais là je ne vois pas d'autre solution si vous avez des idée c'est super
A d'accord, les projet, c'est vraiment des trucs distincts, qui n'ont pas du tout les mêmes champs...µ
Ben dans ce cas, non tu as raison, il va falloir une table par type de projet... Essaie éventuellement d'en regrouper quelques uns (genre climatisation et isolation par exemple, qui auraient quasi tous les champs en commun).
et oui..380 a peu près si c'est pas plus, juste pour les projets, sans compter les autre tables...
donc voilà je voulais juste une confirmation qu'il n y a pas d'autre solution avant de faire 379 table et qu on me dise qu il avait une solution miracle.. sachant qu il faut la table et le bout de formulaire qui va bien...j'ai du boulot!
bah écoute c est juste ze solution c est juste super, sauf que le nombre de param n es t jamais le même selon les catégories donc est ce que je prend la categorie avec le plus de champ et je creer la table projet qui a un nombre de champs egal au nombre de champ de la categorie la plus longue?
Et dès que tu auras un projet avec un nombre de paramètre supplémentaires, faut modifier la table. Mauvaise idée.
Personnellement je verrais les choses comme ça : tu as des clients (mais ça on s'en fout), des catégories (qui recensent une liste de paramètres), des projets, et une liste de valeurs pour les différents paramètres. On aurait donc un truc du genre :
- Client(id, civilite, nom, prenom, ...)
- Categorie(id, id_parent, libelle, ...)
- InfoCat(id, libelle)
- InfoCatMap(id_info_cat, id_cat)
- Projet(id, id_categorie, date création, ...)
- ProjetValeur(id_projet, id_info_cat, valeur)
Je vois pas trop à quoi elle servirait la table projet_valeurparametre. Dans ton exemple, tu mélanges du numérique, des durées, des chaines dans la même colonne. Sinon, j'aurais renommé categorie_parametre en parametre et fais une relation n,n entre categorie et parametre.
Juste une petite question: quand vous dites que ce n'est pas bien d'avoir autant de tables, c'est niveau optimisation/rapidité des scripts ou bien au niveau de la difficulté de s'y retrouver ?
Ben surtout niveau optimisation/maintenance, pour s'y retrouver ça sera galère. Question rapidité, forcément avec une table par projet, c'est difficile de faire plus rapide. Avec les solutions qu'on te propose il te faudra faire des jointures, mais avec des index correctement construits, tu ne verras pas la différence je pense.
Je vois pas trop à quoi elle servirait la table projet_valeurparametre.
</span>
Cette table sert à stocker les valeurs associées à un projet particulier. Comme on ne connaît pas les intitulés des paramètres dont les valeurs sont stockées, il faut une clé étrangère associée au paramètre considéré.
Citation : rotoclap
Dans ton exemple, tu mélanges du numérique, des durées, des chaines dans la même colonne.
</span>
Tous ces types de données peuvent être réduits à du char(N). Où est le problème ?
Citation : rotoclap
Sinon, j'aurais renommé categorie_parametre en parametre et fais une relation n,n entre categorie et parametre.
</span>
Une relation de type (1,n) est plus judicieuse, étant donné que les paramètres semblent spécifiques à chaque catégorie.
Qu'aurais-tu proposé comme schéma de base de données en réponse à ce cahier des charges ?
Cette table sert à stocker les valeurs associées à un projet particulier. Comme on ne connaît pas les intitulés des paramètres dont les valeurs sont stockées, il faut une clé étrangère associée au paramètre considéré.
Tous ces types de données peuvent être réduits à du char(N). Où est le problème ?
Si ça sert qu'à les afficher sur une page web, à la limite pourquoi pas. Mais cette colonne a d'autre vocation, ça va être la merde. Un coup faudra la traiter comme un nombre, comme une chaine, comme un datetime... Tu vas passer ton temps à tout caster à chaque requête, c'est moche et chiant à faire.
Citation : rotoclap
Une relation de type (1,n) est plus judicieuse, étant donné que les paramètres semblent spécifiques à chaque catégorie.
Taguan avait évoqué l'idée que certains projets pouvaient avoir des paramètres en commun, et l'OP semble d'accord puisqu'il a colorié son message en vert. Donc une relation n,n aurait plus de sens si on ne veut pas avoir de redondance.
Citation
Qu'aurais-tu proposé comme schéma de base de données en réponse à ce cahier des charges ?
J'avoue ne pas trop y avoir réfléchi, mais je dirais :
- une table activite
- une table parametre
- une table activite_parametre qui fait office de relation n,n. Avec pourquoi pas une colonne defaut qui pourrait accueillir ce que tu as mis toi dans la colonne valeur de ta table projet_valeurparametre (si j'ai bien compris à quoi sert ta table).
- A la limite une table projet comme la tienne, qui servirait à regrouper les différentes activités par catégorie. Mais je la nommerais pas projet, je trouve que ça ne décrit pas très bien à quoi est destiné la table.
Taguan avait évoqué l'idée que certains projets pouvaient avoir des paramètres en commun, et l'OP semble d'accord puisqu'il a colorié son message en vert. Donc une relation n,n aurait plus de sens si on ne veut pas avoir de redondance.
Dans mon idée, les paramètres ne sont pas associés aux projets mais au types (= catégorie) des projets. On profite alors de la hiérarchisation des catégories pour hériter des paramètres des catégories parentes. En créant les bonnes catégories avec les bons parents, on peut dès lors facilement partager des paramètres entre projet sans redondance.
On a donc ces types de projet qui définissent quels paramètres y sont associées (infoCatMap), mais il faut évidemment une table supplémentaire pour stocker les valeurs de ces paramètres (projetValeur).
Citation : rotoclap
J'avoue ne pas trop y avoir réfléchi, mais je dirais :
- une table activite
- une table parametre
- une table activite_parametre qui fait office de relation n,n. Avec pourquoi pas une colonne defaut qui pourrait accueillir ce que tu as mis toi dans la colonne valeur de ta table projet_valeurparametre (si j'ai bien compris à quoi sert ta table).
- A la limite une table projet comme la tienne, qui servirait à regrouper les différentes activités par catégorie. Mais je la nommerais pas projet, je trouve que ça ne décrit pas très bien à quoi est destiné la table.
j'imagine que ta relation n,n porte sur [activite,paramètre], sauf que plusieurs projets pourront appartenir à la même activité et donc avoir le même paramètre mais avec des valeurs différentes, tu as donc besoin d'une table supplémentaire pour stocker la valeur propre à chaque projet comme je l'ai fait. Tu proposes donc la même chose que moi sans la table projet qui sert à stocker qq données communes à tous les projets (activité/catégorie, date création, budget, etc. etc.)
BDD nombre de table excessif ou pas?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Tutoriel complet MySQL !
Tutoriel complet MySQL !