Unique table héritage ou deux tables?

Question

Supposons que j'ai une table avec les colonnes suivantes (une liste de mots):

word: varchar
contributor: integer (FK)

Maintenant, supposons que je voulais avoir des traductions pour chaque « mot ». Quel serait le mieux? Avoir une deuxième table?

word: integer (FK)
translation: varchar
contributor: integer (FK)
lang: integer (FK)

Ou dans la même table?

word: varchar
translation_for: integer (FK - to the same table)
contributor: integer (FK)
lang: integer (FK)

Supposons que deux scénarios, (1) où je dois tirer un mot traduit avec le mot d'origine, il a été traduit à partir, (2) où je dois tirer uniquement le mot traduit. Sur les deux scénarios, je serais beaucoup plus en utilisant les très "original" mots (à la fois L'option et updateing / encartage ).

Alors, quelle approche serait le mieux pour chaque scénario, ou en général? Je suis enclin à la première approche, depuis lors, mes SELECTs « par défaut » ne doit être qualifié par le lang colonne. Que pensez-vous?

Merci!

Answer 1

Je pense que vous blessez plus tard si vous voulez ajouter une langue plus tard si vous ne normalise pas la base de données maintenant. Avoir une table de mots où le mot est dans la langue par défaut. Il a une carte d'identité. Avoir une table de langue avec un ID (à savoir l'espagnol, 2), et une table de traduction qui a le mot ID, l'ID de langue, et enfin le mot lui-même dans cette langue. Ceci est la table liée.

Utilisez une vue pour vos requêtes, mais pour les insertions et mises à jour, en fonction de votre SGBD, vous devrez peut-être des requêtes difficiles.

Ceci est juste en supposant que vous essayez de fournir la localisation, et sont donc susceptibles d'ajouter plus de langues plus tard. En procédant ainsi, est plus facile que d'avoir à modifier votre base de données pour ajouter des colonnes à chaque fois que vous ajoutez une langue. Si vous avez vraiment besoin que d'une traduction et highly doubt que vous aurez jamais besoin d'un autre, puis juste ajouter une colonne serait bien.

Answer 2

Puisque vous semblez vouloir un « mot » d'avoir une identité distincte d'un « mot traduit », puis 1 pense que la 1ère option répond mieux à vos besoins.

Normalement, je penserais un design plus comme:

PK (Key (varchar), Lang (FK)), Word (nvarchar)

serait plus approprié - où vous faites référence uniquement au texte par sa valeur clé et Lang. Mais, il semble que vous remplacez la clé du « mot d'origine. » - donc qui le rend un peu différent