Discussion :

[Seb des Monts]

bonjour,

Je suis en train de créer des tables dans une base de donnée existante.
J'ai une table "Frais" qui va stocker des frais de natures différentes :
soit des frais d'un devis, soit des frais d'une commande...
Je me pose une question sur comment organiser mes tables.
Je pense à 2 solutions :
solution 1 :

Code :

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

1
2
3
4
5
[b]FRAIS[/b]
CLE_INTERNE_FRAIS int
TYPE_FRAIS             char(1)
CLE_ELEMENT           int
etc...

le champ TYPE_FRAIS indiquerait si le frais est de type devis ou de type commande. Et le champ CLE_ELEMENT serait la clé étrangère vers une table ou une autre selon le tupe.

solution 2 :

Code :

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

1
2
3
4
5
6
[b]FRAIS[/b]
CLE_INTERNE_FRAIS    int
NOM_TABLE_LIEE         char(32)
NOM_CHAMP_CLE_LIE   char(32)
CLE_ELEMENT               int
etc...

le champ NOM_TABLE_LIEE indiquerait directement le nom de la table liée, càd DEVIS ou COMMANDE. Le champ NOM_CHAMP_CLE_LIE indiquerait le nom du champ qui fait lien, par exemple CLE_INTERNE_COMMANDE.
D'ailleurs, on pourrait mettre ces deux champs en un seul en indiquant directement NOM_TABLE.NOM_CHAMP, par exemple T_COMMANDE.CLE_INTERNE_COMMANDE.

Il y a aussi la solution de faire une table FRAIS_DEVIS et une autre table FRAIS_COMMANDE, mais bon, si on a un jour un autre type de frais, c'est moins simple à mettre en oeuvre qu'avec une table générique.

En fait, je connais la solution 1, je l'ai déjà utilisé et ça fonctionne assez bien. Mais je suis assez tenté par la solution 2, encore plus générique du fait de métadonnées dans les enregistrements.... La connaissez-vous ? Avez-vous un avis sur la question ?

merci d'avance pour vos avis

[phili_b]

J'ai du mal à comprendre l'application de ta solution 2. C'est très compréhensible en théorie mais en pratique comment tu codes en SQL ta contrainte?

Code :

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

1
2
3
 
ALTER TABLE Ma_table 
ADD CONSTRAINT MaTable_TableEtrangere_FK FOREIGN KEY (MonChamp) REFERENCES addresses(ChampExterne)

Je suis quasiment sûr que c'est impossible à coder en SQL DDL pour faire des contraintes dynamiques ou alors j'ai lu trop rapidement ton exemple. Dans ce cas tu ferais ta contrainte "à la main" avec du code ? Absolument déconseillé à cause des problèmes d'intégrité.

Ou alors tu fais un modèle complétement en méta-données avec des vraies contraintes ? Mais ce genre de modèle est illisible et n'est utile que dans les applications évolutives parametrées par des fonctionnels (ou dans certaines parties de certaines applications). L'exemple de ce genre d'application sont les ERP.

[Seb des Monts]

en fait, je ne voulais pas gérer de contrainte avec une vraie clé étrangère sur ce champ sinon c'est vrai que je serai bien embêté.
Mais avec quelques triggers ondelete sur les tables liées ça fonctionne pas mal du tout, en tout cas avec la solution 1 que je connais. Je perds un peu de sémantique au niveau de la structure de la base mais je gagne en souplesse il me semble....

exemple en pseudo c++ :

Si on est dans un objet Commande dont je sais que le nom de la table (nom_table_objet) est "Commande" et le champ clé (champ_cle_objet) est "cle_interne_commande", je pourrais récupérer les frais de façon très génériques

Code :

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

1
2
3
4
5
6
"SELECT * FROM FRAIS " 
" WHERE NOM_TABLE_LIEE = '" + nom_table_objet + "'"
" AND NOM_CHAMP_LIE =  '" + nom_cle_objet + "'"
" AND CLE_ELEMENT =  " + string(cle_objet) ;
 
-> récupération des frais

merci pour tes remarques

[phili_b]

en fait, je ne voulais pas gérer de contrainte avec une vraie clé étrangère sur ce champ sinon c'est vrai que je serai bien embêté.
Mais avec quelques triggers ondelete sur les tables liées ça fonctionne pas mal du tout, en tout cas avec la solution 1 que je connais.

tsst tsst. C'est mal de ne pas utiliser des contraintes

Lis ce thread sur developpez.net qui discute de cela pour t'en convaincre :

Modélisation, Méthodes, Architectures, Tests...>Une base de données sans liens ni triggers

[Seb des Monts]

merci bien.
Donc, la bonne solution serait de multiplier mes tables de façon à ne pas avoir des champs qui font "condition" et avoir une gestion correcte des clés étrangères sur chacune des tables COMMANDE, DEVIS, FRAIS_CMDE, FRAIS_DEVIS, ?

[phili_b]

oui. tout à fait.

[Seb des Monts]

merci beaucoup

[Seb des Monts]

bonjour,

J'ai une question qui a quelquechose à voir avec la précédente.

J'ai une table avec un champ clé étrangère, mais je souhaiterai que ce champ ne soit pas obligatoire.
Un exemple pour mieux comprendre :
J'ai une table COMMANDE pour stocker des commandes d'articles, ou pas...
J'ai donc un champ CLE_ARTICLE qui renvoie à une table ARTICLE, ou pas...

Si le champ vaut NULL, ce n'est pas une commande d'article, mais on peut commander autre chose que des articles (amis alors ya pas de lien). Et si le champ n'est pas nul, ben c'est une commande d'article.
Du coup, le champ "fait condition",mais ce n'est pas aussi radical que dans le cas que j'exposais initialement...
Est-ce que ça aussi c'est mal ? et je dois encore une fois dupliquer mes tables por les commandes articles et pour les commandes d'autres choses ? Ou bien est-ce une architecture moins intolérable ?


merci pour vos avis

[SQLpro]

Prévoyez dans ce cas une technique d'héritage.

A lire :
http://sqlpro.developpez.com/cours/m...tion/heritage/

A +

[Seb des Monts]

merci pour ce lien bien intéressant...
Je vais opter pour un modèle physique du genre :

COMMANDE
CLE_COMMANDE
QTE
PRIX
etc...


COMMANDE_ARTICLE
CLE_COMMANDE
CLE_PIECE


merci encore...