1

これは、多言語 Web サイトや e ショップで多くの作業を行ってきた経験豊富な人々にとってより重要な質問です。これは、データベース構造に関する質問などではありません。これは、多言語 Web サイトを保存する方法に関する質問です。翻訳を保存する方法ではありません。多言語 Web サイトは、複数の言語に翻訳できるだけでなく、言語固有のコンテンツを含めることもできます。たとえば、ウェブサイトの英語版は、ロシア語や他の言語の同じウェブサイトとはまったく異なる構造を持つことができます. このような場合に備えて、2 つのストレージ スキーマを考えました。

// NUMBER ONE

table contents // to store some HYPOTHETICAL content
    id         // content id

table contents_loc // to translate the content
    content, // ID of content to translate 
    lang,    // language to translate to
    value,   // translated content
    online   // availability flag, VERY IMPORTANT

ADVANTAGES:
- Content can be stored in multiple languages. This schema is pretty common, except maybe for the "online" flag in the "_loc" tables. About that below.
- Every content can not only be translated into multiple languages, but also you could mark online=false for a single language and disable the content from appearing in that language. Alternatively, that record could be removed from "_loc" table to achieve the same functionality as online=false, but this time it would be permanent and couldn't be easily undone. For instance we could create some sort of a menu, but we don't want one or more items to appear in english - so we use online=false on those "translations".

DISADVANTAGES:
- Quickly gets pretty ugly with more complex table relations.
- More difficult queries.



// NUMBER 2

table contents // to store some HYPOTHETICAL content
    id,        // content id
    online     // content availability (not the same as in first example)
    lang,      // language of the content
    value,     // translated content

ADVANTAGES:
1. Less painful to implement
2. Shorter queries

DISADVANTAGES:
2. Every multilingual record would now have 3 different IDs. It would be bad for eg. products in an e-shop, since the first version would allow us to store different languages under the same ID and this one would require 3 separate records to represent the same product.

最初のストレージ オプションは、2 番目のストレージ オプションの代わりに簡単に使用できるため、優れたソリューションのように思えますが、その逆は簡単ではありません。唯一の問題は...最初の構造が少しやり過ぎのように見えることです（製品の保管などの場合を除く）

だからあなたへの私の質問は：

最初のストレージ オプションを実装することは論理的ですか? あなたの経験では、そのようなソリューションが必要になる人はいますか?

4

2 に答える 2

1

私たちが自問する質問は常に次のとおりです。

複数の言語で内容が同じで、関係が必要か?

翻訳可能なモデル

答えが「はい」の場合、翻訳可能なモデルが必要です。したがって、同じレコードの複数のバージョンを持つモデル。したがって、レコードごとに言語フラグが必要です。

長所: たとえば、どのコンテンツがまだ翻訳されていないかを確認できる構造を提供します。

言語ごとにレコードを分離します が、多くの場合、別の解決策の方が優れていると考えられます。両方の言語を完全に分離するだけです。これは主に CMS ソリューションで見られます。ストーリーは翻訳されているだけでなく、別のものです。たとえば、国 1 では、別のメニュー構造、その他のニュース項目、その他の製品、およびその他のページがあります。

長所: 完全な柔軟性と、他の言語からの予想外の記録がありません。

例 雑誌を書くようなものです。雑誌を書いてから、別の言語に翻訳できます。はい、それは可能ですが、現実の世界では、コンテンツが構造的に異なることがますます多く見られます。人々は驚かされることを好まないので、コンテンツが間違った言語で表示されたり、ページが重複して作成されたりしないようにするために、多くの手順が必要です。

ロジックを共有する ので、ほとんどの場合、ビューを共有し、ボタン、入力などを翻訳可能にしますが、コンテンツは分離したままにします。すべての管理者が自分の領域で作業できるようにします。一部のレコードがすべての言語で利用可能であることを確認する必要がある場合は、それらの間にリンク (適切にリレーショナル) を作成することでいつでもだますことができますが、これはほとんどの場合使用する標準ではありません。

製品のような本当に翻訳可能なレコード モデルなどの作成に柔軟に対応できるため、要件に基づいてモデルの使用方法を決定することができます。すべての人に有効な一般的な解決策を探すつもりはありません。データに基づくソリューションが必要です。

于 2012-10-15T08:52:07.727 に答える
0

Luc が説明しているように、翻訳可能なモデルが必要であると仮定すると、コンテンツ テーブルの値の列に対して、ある種の特殊文字で区切られたキーと値のペアの形式を考え出すことをお勧めします。例：

@en=英語用語@de=ドイツ語用語

UDF (T-SQL のユーザー定義関数) を使用して、指定された言語に基づいて適切な用語を設定/取得できます。

選択する場合:

コンテンツから id, dbo.GetContentInLang(value, @lang) を選択

更新の場合:

コンテンツ セットの更新値 = dbo.SetContentInLang(value, @lang, new_content) ここで、id = @id

UDF:

を。パフォーマンス ヒットがありますが、これは content テーブルと content_loc テーブルの間で行う必要がある結合の場合にも当てはまります

と

b. 実装はやや困難ですが、データベース全体で実質的に再利用可能です。

アプリケーション/UI レイヤーで上記を実行することもできます。

于 2013-03-02T22:10:08.877 に答える