Version imprimable
un produit peut avoir plusieurs tarifications ou non?
En effet, je rejoins papajoker et punkoff, tu as un problème de conception il me semble.
Si un produit peut avoir plusieurs tarifications et qu'une tarification peut correspondre a plusieurs produits, alors il te faut faire une table d'association avec comme clé la concaténation des 2 clés primaire...
@whitetiger1980 et si tu désires encore plus de tutos pour les longues soirées d'hiver :
http://www.weboplanet.com/analyse/
a prendre
ANALYSE_ch2_mea.pdf
ANALYSE_ch3_mrd.pdf
mais un produit peut avoir plusieurs codes tarifs dans mon cas ...
donc je ne peux pas mettre dans la même colonne tte les référence de code tarifs.
c'est pour ça que je voulais une colonne par code tarifaire comme ça sur chaque ligne de produit je peux dire par exemple "0" (pour une colonne de tarif non utilisé) et "1" (pour une colonne de tarif utilisé)..
exemple :
d'un côté création des codes tarifs :
I-"l'utilisateur ajoute un tarif"
code 1 / libellé / prix
code 2 / libellé / prix
code 3 / libellé / prix
etc...
(=>enregistrement dans la table tarif (colonnes : code / libellé / tarif) une ligne pour chaque code enregistré par l'utilisateur)
de l'autre il selectionnera pour chaque produit si le tarif s'applique ou pas :
II - "l'utilisateur selectionne les tarifs en fonction des produits"
code 1 code 2 code 3 ...
produit a 0 1 0
produit b 1 1 0
produit c 0 1 1
etc...
(=> enregistrement dans la table produit (colonnes : code 1 / code 2 / code 3 etc...) une ligne pour chaque produit permettant d'enregistrer le choix fait par l'utilisateur : 0 le produit ne dépend pas de ce code tarifaire, 1 le produit dépendde ce code tarifaire)
voilà ce que je voulais faire à la base
et donc voila pourquoi je voulais pouvoir ajouter / supprimer des colonnes dans une table.
Je ne veux pas juste indexé un code d'une table à l'autre
oui, on a bien compris.
Et ce cas se modélise avec une table d'association, point.
déjà lisez ca :http://dev.mysql.com/doc/refman/5.6/...unt-limit.html
Et si cela ne vous a pas convaincu, commencez à réfléchir aux méthodes que vous allez devoir implémenter pour faire des recherches d'article par tarif.
Ou même plus simplement d'afficher les différents prix associé à un article.
Comparez l'usine que celà implique par rapport à un modèle correct (2 jointures ...)
Je ne parlerai pas des perfs qui vont s'effondrer au fur et à mesure que la base cliente va grossir.
avec tout ca j'ai de quoi potasser et "me tirer un peu les cheveux" lol
je vais regarder tout ça et voir ce que je vais pouvoir en sortir ...
Désolé si pour vous cela vous semble simple mai smoi je reste un débutant autodidacte donc j'apprend à mesure :)
J'ai lu les liens proposé, et vu les différentes normalisation pour les BDD, mais cela ne répond pas à mon besoin.
Par rapport à l'usage que j'ai dans le site, la réponse reste de pouvoir ajouter et supprimer une colonne dans une table de la base de donnée.
Je pense pourtant que si ca repond a ton besoin.
Si tu as encore des doutes exposes nous le probleme complet, on t'aidera a l'etudier.
mon problème n'est pas de créer des relations entre table pour éviter des redondances (en résumé)
la problèmatique est la suivante :
dans un catalogue il y a :
_ X catégorie contenant Y produits qui eux mêmes contiennent Z articles
en parallèle il y a des options de broderie, pour chaque option il y a un code de tarification.
_ il y a n code de tarification de broderie
on veut pouvoir répartir les differents codes de tarification broderie en fonction des Y produits.
ok pour la table produits d'un côté, et la table tarification broderie de l'autre.
Mais créér une table R_prod_tarif par exemple ne me semble pas approprié car cela engendre une ligne pour chaque couple #id_produit/#id_tarif
un peu lourd je pense aussi en cas de modification exemple :
_ si on supprime un code de tarif => il faudra supprimer en parallèle toutes les lignes #id_tarif correspondante dans la table r_prod_tarif
tandis que si on gere par un système d'ajout/suppr de colonne on aurait :
_ la table tarif
_ la table produit
quand on crée un tarif A => ça créé une colonne A dans la table produit
=> chaque ligne produit a alors dans la colonne une valeur NULL si ce produit n'est pas impacté par ce tarif, ou une valeur #id_tarifA si le produit est impacté par ce tarif.
Si on supprime le tarif cela supprime donc directement la colonne puisque le tarif n'existera plus.
si on modifie un produit pour dire qu'il a acces maintenant a ce tarif alors la valeur NULL prend la valeur #id_tarifA
Je ne sais pas si cela vous semble plus clair maintenant ?
Tu ne dois pas te poser ce type de question "c'est un peu lourd"Citation:
Envoyé par whitetiger1980
Tu dois juste te demander si c'est une relation simple ou multiple :
tu as plusieurs code de tarification pour un produit
et(ou) plusieurs produits pour un code de tarification
En fonction de cette réponse, "le format" de tes tables est obligatoire, que se soit lourd,complexe ou simple n'a aucune importance.
Ici tu viens de faire le MCD... et tu devrais passer à l'étape suivante
a revoir pour toi le passage : MCD - MLD
http://cyril-gruau.developpez.com/merise/
Bonjour,Citation:
Envoyé par whitetiger1980
Vous remettez en question des années de pratique de la modélisation de donnée (je ne parle pas de mon cas mais de la méthode générale)
Ceci sur un simple "je penses que".
La seule réponses constructive que je pourrais émettre :
Faites 2 prototypes avec les deux solutions, et faites des tests de monté en charge avec des utilisateur simultanés.
Le verdict (que l'on peut extrapoler sans se poser de question) :
- votre méthode : l'application s'effondrera assez rapidement au moindre ajout / supp de tarif
- la méthode normale : pas de problème dans les limites des perfs du serveur.
pour répondre à la question :
un code tarif peut s'appliquer à plusieurs produits
ET
un produit peut avoir plusieurs code de tarif
Bonsoir,
Vous tourner en rond là si je puis me permettre !
@Punkoff vous a donné la solution entre autre.
Qu'est-ce qui vous dérange dans une Table d'association ?
La redondance de quoi ? Au contraire.
et 'ON.... CASCADE' cela existe.
(enfin j'ai lu en diagonale)
et là je retourne couper du Bois en Alaska :roll:
Je ne comprends pas votre point de vue, j'avoue j'ai du mal là !Citation:
Mais créér une table R_prod_tarif par exemple ne me semble pas approprié car cela engendre une ligne pour chaque couple #id_produit/#id_tarif
un peu lourd je pense aussi en cas de modification exemple :
_ si on supprime un code de tarif => il faudra supprimer en parallèle toutes les lignes #id_tarif correspondante dans la table r_prod_tarif
tandis que si on gere par un système d'ajout/suppr de colonne on aurait :
_ la table tarif
_ la table produit
;)
on cascade ??
on cascade permet de supprimer les elements join lors de la suppression d'un tuple (d'une ligne)
Voici le résultat de ta solutions a long terme :
t_produit (id, descption, ... , prix_1, prix_2, prix_4, ...., prix_9999999)
Donc chaque alter table vu la taille de ta table prendrait du temps...
en plus chaque ligne de ta table aurait 9999999 prix, donc si tu supprimes ta colonne c'est pour TOUT les produits...
=> en clair vraiment pas une bonne solution et conceptuellement pas juste.
alors qu'avec une table d'association, ta table produit ne bouge pas, ta structure non plus, donc tu ajoutes/modifies/supprimes juste des elements dans la table d'association
ok j'ai ma table prix et ma table produit
je créée ma table r_prod_tarif pour les associations des deux mais dans ce cas en langage php ca donnerai quoi quand on créer un nouveau prix ? et surtout quand on en supprime un ?
la cascade je vois pas comment faire, je sais faire les requêtes simples :( je débute
Prenons un exemple (2 articles, 4 tarifs) :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Suite à la création des tarifs, vous souhaitez associer les tarif 1 et 4 à l'article 1, il faudra donc insérer 2 lignes dans la table d'association :
Code:
2
3
4
5
6
Lors de la suppression d'un article ou d'un tarif, vu qu'il y a des contraintes d'intégritées il faudra supprimer en 1er les lignes présentes dans la table de relation puis celle dans la table mère.
Au vu de l'exemple ci-dessus, si nous voulons supprimer le tarif 4 on aura deux requetes SQL à executer (dans la même transaction) :
Code:
2
3
Concernant la clause "on cascade" je vous déconseille de la mettre en place, ca évite des catastrophe en prod, suite à un delete malencontreux.
Je rejoins punkoff sur le on cascade, perso je suis pour maîtriser entièrement ce qu'il se passe en BD et non pour avoir des actions automatiques.
Si tu souhaites quand meme regarder a quoi ca sert => http://dev.mysql.com/doc/refman/5.0/...nstraints.html
c'est carrement plus clair comme ca punkoff merci d'avoir été pédagogue sur ce coup là
et merci aussi à toi marcuscircus tu as été patient et très pédagogue aussi