Discussion :

[cortex024]

Bonjour,

je vais avoir une table principale de personnes, qui sera reliée a pas mal d'autres tables, en guise de "details".

je me demandais si il valait mieux niveau performance, évolutivité, conception, mettre des clés étrangères sur ma table principale, ou si il valait mieux ne pas en mettre, et référer dans toutes mes tables détails avec un champ indiquant à quelle personne ce détail appartient.

Les clés étrangères dans la première table pourrait faciliter la programmation, mais la seconde possibilité permettrait une évolutivité facile sans modification de table.

[qi130]

Bonjour,

je vais avoir une table principale de personnes, qui sera reliée a pas mal d'autres tables, en guise de "details".

je me demandais si il valait mieux niveau performance, évolutivité, conception, mettre des clés étrangères sur ma table principale, ou si il valait mieux ne pas en mettre, et référer dans toutes mes tables détails avec un champ indiquant à quelle personne ce détail appartient.

Les clés étrangères dans la première table pourrait faciliter la programmation, mais la seconde possibilité permettrait une évolutivité facile sans modification de table.

Sans aucun doute, l'utilisation de FK est largement préférable et recommandée.
D'ailleurs, elles servent à ça

De plus, tu parles d'évolution facile et sans FK, ce sera tout sauf facile. Si tu fais l'impasse sur les FK, ce sera par programmation que devront être gérées toutes les dépendances fonctionnelles, et naturellement, si tu ajoutes 1 table, c'est tout un pavé de contrôles qu'il faudra intégrer à l'appli.

Allez, je te le fais à un bon prix une FK non mise en place doit peser entre 20 et 40 lignes de code (selon le langage).

A toi de voir...

Enfin, un modèle complet (avec les FK donc) permet la retro-conception, ce qui facilite l'appropriation de l'appli, et donc sa maintenance. Coté technique, un bon DBA pourra tuner plus finement la base.

[fsmrel]

Pour compléter ce que vous a dit Qi130, je rappelle que les clés étrangères sont là pour garantir l’intégrité référentielle.

Imaginez que les personnes sont des clients qui achètent des voitures à crédit ou qui prennent des contrats d’assurance-vie, ou que sais-je encore et donc qu’il faille mettre en œuvre une table Contrat dont les lignes ont une durée de vie certaine. Grâce aux clés étrangères, vous êtes sûr qu’en face d’un contrat il y aura toujours un client : si vous supprimez un client, soit le système le refusera parce que l’utilisateur aura défini une règle de gestion selon laquelle on ne supprime pas un client qui a un contrat (ce que vous avez traduit au niveau de la base de données par une clause Restrict ou No Action pour la clé étrangère) ou bien, la suppression sera acceptée parce que selon la règle de gestion, la suppression d’un client entraîne celle de ses contrats (clause Cascade).

Avec les clés étrangères :

1) l’intégrité de votre système est garantie par le SGBD

Si vous n’en voulez pas, vous prenez en charge vous-même l’intégrité par vos programmes et vous risquez tout simplement de vous retrouver un jour avec des milliers de contrats actifs mais pour lesquels il n’y a plus de clients en face. Je dis cela pour l’avoir observé chez mes propres clients : au départ tout va bien, mais avec le temps, comptez 30% de contrats orphelins.

2) vous sous-traitez des règles de gestion au SGBD

A défaut, ça sera à vous aurez de programmer ces règles, comme vous le dites :

Les clés étrangères dans la première table pourrait faciliter la programmation

Quand vous écrivez

la seconde possibilité permettrait une évolutivité facile sans modification de table

Je ne vois pas en quoi la mise en œuvre d’une contrainte "Foreign key" gêne l’évolutivité. Vous pouvez pour une raison ou une autre débrancher cette contrainte, pour la rebrancher avant de remettre les tables à la disposition des applications.

Un conseil : par référence aux trois petits cochons, préférez construire une maison en briques plutôt qu’en paille et implantez l’intégrité référentielle. Attention au loup.