Discussion :

[guste]

Bonjour,

J'ai une table COUNTRY qui contient une clé primaire 'Id' [int] un champ 'TranslationdId' [int].
J'ai une deuxième table TRANSLATION dont la clé primaire est composé de 2 champs : 'Id' [int] et 'Lang' [char(5)].
Je voudrait qu'il ne soit pas possible d'insérer un enregistrement dans COUNTRY si la valeur du champ 'TranslationId' n'existe pas dans au moins un champ 'Id' de la table TRANSLATION.

Il ne s'agit donc pas d'un clé étrangère car le champ 'Id' de la table TRANSLATION n'est pas unique (c'est le couple 'Id'/'Lang' qui est unique). J'ai donc essayé avec un contrainte CHECK mais ça ne fonctionne pas :
...
[TranslationId] [int] NOT NULL CHECK (TranslationId IN(SELECT DISTINCT [Id] FROM [Translation])),
...

Savez-vous comment je peux gérer ce soucis? Et si c'est possible, avez-vous des idées sur les impacts en performance?

Merci d'avance

[elsuket]

Bonjour,

Vous devez pour cela ajouter également la colonne 'Lang' à la table COUNTRY pour pouvoir créer une clé étrangère.

Cela dit il vaudrait mieux créer une clé subrogée, c'est à dire une clé purement technique comme clé primare, et ajouter une contrainte d'unicité sur la table TRANSLATION sur les colonne 'Id'et 'Lang'.

La nouvelle clé primaire (subrogée) est alors référencée par la table COUNTRY.
Les jointures sur des colonnes de type CHAR, c'est moche et par performant ...

@++

[guste]

OK, merci pour la réponse rapide. En fait j'ai une relation n-n entre ma table COUNTRY et ma table TRANSLATION, un même pays a plusieurs traduction (en fait un seul id de traduction mais plusieurs langue) et une traduction peut correspondre à plusieurs pays.

Donc d'un point de vue relationnel, je devrait avoir une table de liaison du type COUNTRY-TRANSLATION, ce qui résoudrait mon soucis proprement.

Cependant, j'ai une quinzaines d'autres table similaires à la table COUNTRY et, via ce tour de passe passe, je voulais m'éviter de devoir gérer autant de tables de liaisons... A priori ce n'est pas possible, ou alors de façon applicative (sans contrainte dans le SGBD) et là, impossible d'assurer une cohérence des données...

[aieeeuuuuu]

je voulais m'éviter de devoir gérer autant de tables de liaisons...

Attention, en voulant faire l’économie de la création de quelque tables, vous risquez d'engendrer un surcout (pour la création des requêtes qui seront plus complexes, sans parler de leur temps d’exécution) que vous ne constaterez que... trop tard

[elsuket]

Donc d'un point de vue relationnel, je devrait avoir une table de liaison du type COUNTRY-TRANSLATION, ce qui résoudrait mon soucis proprement.

ça c'est clair.

Cependant, j'ai une quinzaines d'autres table similaires à la table COUNTRY et, via ce tour de passe passe, je voulais m'éviter de devoir gérer autant de tables de liaisons

Non, il n'a effectivement pas de magie : un modèle est bon ou il ne l'est pas.

A priori ce n'est pas possible, ou alors de façon applicative (sans contrainte dans le SGBD) et là, impossible d'assurer une cohérence des données...

C'est tout à fait exact mais ce n'est pas la seule raison.

Bonne lecture et @++