Discussion :

[xoum89]

Bonsoir à tous, voila j'ai besoin de votre aide car ceci n'est pas commun et je ne sais même pas si on peut le faire (je pense que oui).

Structure de la base de donnée

J'ai deux tables, avec des champs respectif :
Menu
-idMenu
-nom
Plats
-idPlats
-nom

J'ai une Séquence
Permettant à l'incrémentation des id De menu et de Plats.

J'ai un trigger
Qui permet de faire cette incrémentation avant chaque insertion sur les tables Menu et Plats.

Donc en gros Les Id de plats et de menu son des id commun, il ne peut y avoir des même numéro dans ces champs la.

Mais je voudrai rajouter une KEY étrangère à ces deux champs pour plus de sécurité.
Rajouter une FOREIGN KEY sur une table cela est facile mais la rajouter à une sequence je ne sais pas faire d'ou ma demande d'aide.

Merci de votre aide.

[Waldar]

Mauvaise modélisation, mauvaise solution technique !

Qu'est-ce qui, fonctionnellement, peut justifier ceci ?

Les Id de plats et de menu son des id commun, il ne peut y avoir des même numéro dans ces champs la.

[xoum89]

Des plats son composés d'ingrédients (je vous est pas mis cette table)
Des menus son composé de plat.

Une personne peux commander soit des plats soit des menus.
Les prix seront différents si vous prenez un menu que si vous prenez les plats en séparés.

Comment structuré la table autrement sinon ?

Une autre table existe :
Commande
-idClient
-Choix (correspondrai a l'id du menu ou du plat)

Je compté faire une view pour la facture qui relierai la table commande avec la table menu ou plats, pour avoir le prix final du client.

Si je veux faire cette foreign key sur la séquence c'est parce que je suis coincé au niveau du choix client dans la table commande.

Merci de votre réponse au passage.


Ps : si vous changez la table "commande"
En rajoutant des champs du genre :

commande
-idClient
-idmenu
-idPlat

Cela permet d'avoir les ID en primary key sur les tables Menu et Plats.
Mais cela implique d'avoir une structure de table qui n'est pas en troisième forme normal (je suis maniaque)
Car à chaque fois un champs sera rempli en vide.

ex : si une personne commande un plat la table sera du style

idClient idMenu idPlats
1 NULL 3



Ps²: Pour créer la table commande je me suis basé sur le client, en me basant sur les menu et plats je peux peut être faire d'une autre manière.

Menu_commandé
-idMenu
-idClient

Plats_commandé
-idPlats
-IdClient

Cela impliquera que je serai obligé d'aller chercher le prix de la commande final du client sur deux tables différentes, n'est ce pas un peu dérangeant?

[mongilotti]

il faut simplifier et utiliser:
une table type_commande(ID, NOM_TYPE)
qui peut contenir tous types meme au futur (1,MENU) (2,PLAT) ...

la table commande (ID, ID_TYPE, QTE ,...)

inspire toit de ça!

[pachot]

Bonjour,

Pour moi, la bonne manière de modéliser en relationnel 'Une personne peux commander soit des plats soit des menus.' c'est ce que tu évoques:
une Commande a :
- un idMenu , foreign key sur Menu
- et un IdPlat, foreign key sur Plat
- une contrainte check ( idMenu is null or IdPlat is null )

D'autres trouveront comme toi que ce n'est pas beau, pas conforme à la théorie, par en forme normale.

Pour moi la bonne manière de faire sur les SGBD relationnels tels qu'ils sont implémentés aujourd'hui.

L'interêt d'être en forme normale, c'est d'éviter des inconsistences de données. Mais dans cet exemple, il n'y a pas d'inconsistences car les foreign key et la contrainte check vérifient exactement toutes les règles métier.

Alors que dans ta solution, tu ne peux pas vérifier toutes les règles métiers (car tu ne peux pas mettre la foriegn key qu'il te faudrait, vers 2 tables) par des contraintes d'intégrité. Bien sûr, tu peux les vérifier en procédural, par des triggers, mais de manière beaucoup moins performante: il faudrait locker toutes les tables pour faire cette vérification.
Ou alors il faudrait rester dans la théorie (relationnel, formes normales, pas de null, ...) et cette théorie comprends une contrainte d'intégrité 'ASSERTION' qui permet de tout vérifier. Mais dans la vraie vie, l'assertion n'a pas été implémentée par la pluspart des SGBDR car il n'y a pas de solution efficace.

Ta deuxième solution (menu_commandé et plat_commandé) a pour moi le problème que la règle 'Une personne peux commander soit des plats soit des menus.' n'est pas implémentée par une contrainte d'intégrité.

Cordialement,
Franck.