Devrais-je toujours concevoir autour de clés étrangères?

Question

Par exemple, j'ai une table de recherche de balises qui joint des balises à 3 types de tables différents (ObjectTypes). Chacun a des balises, mais elles ne sont pas partagées.

Donc, je pourrais le faire

Tagid | ObjectType | ObjectId |

Et quand je rejoins la table ensemble, je voudrais juste filtrer par type d'objet avant de rejoindre.

Maintenant je sais que cela casserait la capacité de faire une clé étrangère sur le sens de la colonne ObjectId pourrait être l'une des trois tables.

Question est .. Est-ce une chose terrible? si oui, pourquoi?

L'autre option consiste à créer une table de correspondance pour chaque objet, sauf s'il existe une meilleure méthode.

Answer 1

Ne pensez pas aux clés étrangères, déterminez si vous souhaitez appliquer l'intégrité référentielle au niveau de la base de données. Sans l'intégrité référentielle imposée par le SGBDR, vous devrez l'appliquer vous-même dans votre application, ou vous feriez un maximum pour écrire des contraintes de base de données compliquées pour faire ce que le SGBDR vous donne déjà sous forme de clés étrangères.

En pratique, cependant, vous n'allez pas avoir de bonnes raisons de stocker trois tables conceptuelles dans une grande table. Ce n'est pas une bonne idée de stocker plus d'une table de données dans la même table juste parce qu'elles ont les mêmes colonnes. Ils ont le même schéma, mais ils ne sont pas la même table.