2010-08-09 7 views
1

Je travaille sur un projet et nous avons créé des tables qui stockent des références sous forme de combinaison de deux colonnes.Une colonne de référencement doit-elle être limitée à une seule table?

Un exemple: nous avons une table 'alerts', qui est utilisée pour fournir des informations à l'utilisateur. Une alerte peut faire référence à un certain nombre de choses différentes, vous pouvez être averti d'un nouveau message, ou si un autre utilisateur vous a mentionné. Ces alertes ont différents types et référencent différents types de données. L'alerte de message doit diriger l'utilisateur vers la page de message, et l'alerte de mention doit diriger l'utilisateur vers la page des autres utilisateurs.

Nous utilisons les colonnes alert.type et alert.article et le type de stockage = MESSAGE ou type = MENTION et l'article comme la clé étrangère à soit le message ou la table utilisateur. Cela me frappe comme une sorte de mauvaise conception, écrasant des références à deux tables différentes dans la même colonne. Cependant, puisque nos tables sont InnoDB, j'ai eu du mal à justifier cela. J'espère pouvoir obtenir des commentaires d'experts pour savoir pourquoi c'est un bon/mauvais choix. Je pense que cette approche pourrait avoir des problèmes avec les jointures indexées, mais je n'en sais vraiment pas assez.

Je suppose que les autres options sont une colonne par type, ce qui rend la table assez large, et plein de null, ce qui ne me dérange pas vraiment, mais certains trouvent fastidieux; ou une table 'enfant' pour chaque type qui semble le plus correct, mais un peu exagéré?

Cheers,

+0

Je suis d'accord avec votre évaluation: la référence de variable actuelle rend impossible l'utilisation de clés étrangères réelles, ce qui est un deal-breaker pour moi. Soit deux colonnes de clé étrangère facultatives, soit deux tables de jointure est fine IMO. – bobince

Répondre

0

Voici quelques raisons:

  1. vous ne pouvez pas utiliser les clés étrangères, comme dit précédemment.
  2. vous ne pouvez pas utiliser un index unique (puisque le message/id utilisateur peut être reproduit dans le tableau, ce qui signifie que vous pouvez avoir en double message_ids aussi ...)
  3. vous devez expliquer à tout le monde

"Plein de null"? Mignonne. En outre, il ne serait que 1/2 plein de null (une colonne aurait toujours une valeur).