1

次の列（単語のリスト）を持つテーブルがあるとします。

word: varchar
contributor: integer (FK)

ここで、「単語」ごとに翻訳を作成したいとします。何が一番いいでしょうか？2番目のテーブルがありますか？

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

またはすべて同じテーブルにありますか？

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

2つのシナリオを想定します。（1）翻訳された単語を翻訳元の単語と一緒にプルする必要がある場合、（2）翻訳された単語のみをプルする必要がある場合です。どちらのシナリオでも、「元の」単語をはるかに多く使用します（SELECTingとUPDATE / INSERTINGの両方）。

では、各シナリオ、または一般的に、どのアプローチが最適でしょうか？私は最初のアプローチに傾倒しています。それ以降、私の「デフォルト」のSELECTはlang列で修飾する必要がなくなります。どう思いますか？

ありがとう！

4

2 に答える 2

1

データベースを今正規化しないと、後で言語を追加したい場合に後で損をすると思います。単語がデフォルト言語である単語テーブルを用意します。IDが付いています。ID (つまり、スペイン語、2) を持つ言語テーブルと、単語 ID、言語 ID、そして最後にその言語の実際の単語を持つ翻訳テーブルを用意します。これがリンクテーブルです。

クエリにはビューを使用しますが、挿入と更新には、DBMS によってはハード クエリが必要になる場合があります。

これは、ローカリゼーションを提供しようとしていることを前提としており、後でさらに言語を追加する可能性があります。この方法は、言語を追加するたびにデータベースを変更して列を追加するよりも簡単です。本当に必要な翻訳が 1 つだけで、別の翻訳が必要になる可能性が非常に低い場合は、1 つの列を追加するだけで問題ありません。

于 2009-04-03T21:30:53.733 に答える
0

あなたは「単語」に「翻訳された単語」とは別のアイデンティティを持たせたいように思われるので、1番目のオプションはあなたのニーズをよりよく満たすと思います。

通常、私は次のようなデザインだと思います。

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

より適切です-テキストをそのキーとラングの値でのみ参照する場合。ただし、Keyを「元の単語」に置き換えているようです。そのため、少し異なります。

于 2009-04-03T21:27:47.220 に答える