Est-ce une mauvaise idée d'avoir une clé primaire composite qui contient une clé étrangère?

Question

Je suis la conception d'une base de données et ont les deux tableaux suivants:

• t_model (avec des champs: model_id (PK), model_name)
• t_model_version (avec des champs: model_id (PK, FK), model_version (PK), start_validity_date, end_validity_date)

Comme on peut le voir, t_model_version son PK est un composite PK. L'un des champs de la PK est également un FK (le PK de t_model). Je me demandais si c'est une bonne ou une mauvaise pratique? Je voudrais éviter d'avoir des difficultés plus tard que je ne peux pas encore prévoir ...

t_model détient différents modèles (par exemple différents modèles/formes fonctionnelles pour prédire la croissance macroéconomique). t_model_version contient les numéros de version par modèle (par exemple, une version différente d'un modèle signifie que la forme fonctionnelle est conservée mais que les estimations de coefficient ont été mises à jour).

Edit: Ma question ne porte pas sur comment d'ajouter un FK lorsque le champ d'intérêt est déjà partie d'un PK composite, mais si ce une bonne pratique. Par conséquent, ma question n'est pas une duplication de Composite Primary Key + Foreign Key.

Answer 1

Le plus gros problème est que le champ FK puisse également être nul dans vos données car cela pourrait causer des problèmes d'unicité. Cependant, compte tenu de votre structure de terrain, je trouverais peu probable que vous autorisiez des valeurs nulles dans ce domaine dans tous les cas.

Answer 2

Il suffit de les déclarer où vous les trouverez donc le SGBD peut les appliquer - à moins que déjà sous-entendus par d'autres déclarations - sauf que vous devez déclarer une liste de colonnes PRIMARY KEY ou UNIQUE NOT NULL qui est référencé par un FOREIGN KEY.

Déclarez un NOT NULL lorsqu'une colonne ne peut pas être NULL. Déclarez un PRIMARY KEY ou UNIQUE NOT NULL lorsque les valeurs de sous-niveaux sont uniques et non nulles (et ne contiennent pas de sous-liste plus petite, ce qui impliquerait que). Déclarez les autres sous-domaines UNIQUE (qui ne contiennent pas de plus petits, ce qui impliquerait que). Déclarez un FOREIGN KEY lorsque les valeurs du sous-programme doivent apparaître ailleurs sous la forme PRIMARY KEY ou UNIQUE NOT NULL (et une chaîne de FOREIGN KEY ne le dit pas déjà). Ensuite, si nécessaire, déclarez les sous-répertoires restants référencés par FOREIGN KEY s.

PS Il ne sert à rien de s'inquiéter de chaque combinaison de notions que vous apprenez. Lisez à propos de la modélisation de l'information et des bases de données relationnelles pour apprendre la bonne conception.

Answer 3

C'est très bien - même si vous utilisez des clés naturelles. Ce n'est pas nécessaire si vous utilisez des clés de substitution.