2

現在、特定の動的データをさまざまな言語で利用できるようにする必要がある Web サイトを開発しています。現在の言語は 3 つですが、将来的にはさらに追加する予定です。

ページがあり、3 つの異なる言語でコンテンツを提供したいというこの最初のシナリオを想像してみてください。私のデータベースのページは次のように保存されます。

ページ UML

私が持っている言語ごとに、ページの新しい翻訳コンテンツを作成するので、これはうまく機能します。

しかし、プロジェクトが進むにつれて、翻訳されたデータが必要になる状況が増えてきました。次の図は、タイプ、サブタイプ、およびステータスを持つ製品の例です。このデータはすべて、さまざまな言語で利用できる必要があります。

製品 UML

たとえば、IDだけを保持するテーブルになってしまうので、これは少しやり過ぎではありませんか? また、翻訳されたコンテンツを保持する必要があるテーブルごとに、新しいテーブルが必要です。

より良いアプローチはありますか？

4

2 に答える 2

2

いくつかの外部キーと「データベースの純度」を犠牲にしたい場合は、次のようにすることができます。

CREATE TABLE LocalizedTexts(OwnerType byte PK, OwnerID int PK, LanguageID int PK, Text string)

「所有者」 (製品、ステータス名、タイプなど) ごとに整数定数を割り当てますOwnerType。にLocalizedTextsは、所有者タイプ、所有者 ID (または、...) および言語 ID で構成される主キーがProductIDありStatusNameIDますTypeID。

OwnerTypeが一意でない場合のあいまいさを解消しOwnerIDます (複数のテーブルに由来するため)。

これは、適切に拡張可能で正規化されたスキーマです。唯一の欠点は、ここで FK を使用できないことです。

于 2013-04-14T18:23:19.503 に答える