0

たくさんの情報を載せた新しいグローバルウェブサイトのプロジェクトを始めています。この情報はすべてローカライズする必要があります。私はかなりの数のサイトを構築しており、それらのほとんどは複数の言語で部分的にしか作成されていませんが、それほど多くのローカリゼーションで何かをしたことはありません。

次のデータがあると仮定します。

国、都市、店舗、製品、製品の生産者。

ストア、製品、および製品プロデューサーのエンティティでは、データをローカライズすることができます。国の言語は必須ですが、その隣にN個の言語を追加できます。これは他の国の人々に情報を表示するために使用され、またこれについて検索する必要があります。

私の最初のアイデアは、ローカライズされたテーブルごとに、IDと、ローカライズできないメタデータだけを使用して親テーブルを作成し、次に、親テーブル、国コード、およびローカライズされたフィールドへの参照を使用して子テーブルを作成することです。

この構造は結合を引き起こす可能性があるため、パフォーマンスに悪影響を与える可能性があります。誰かがこの構造の経験がありますか?考慮すべきことはありますか?これをより良くする他の方法はありますか?

4

1 に答える 1

1

まず、パフォーマンス面でいくつかの結合をミックスに投入することについて心配する必要はありません。私たちが言うように、時期尚早の最適化はすべての悪の根源です。 最初にすっきりとしたデザインを作成してから、パフォーマンスについて心配します。

あなたが本当にする必要があるのは、あなたがローカライズしているものとその理由を正確に考えることです。LedgerSMBで行うことは、まさにあなたが提案していることです。つまり、事実を含むテーブル、そして翻訳を含むテーブルです。

すべてのパフォーマンスを維持するための鍵は、送受信される実際のクエリの数を減らすことを検討することです。60ほどの文字列をプルする結合を実行してから、アプリがそれらを処理するのは1つのことです。パフォーマンスの面では、データベースに60の異なるクエリを送信して、それぞれ1つの文字列をプルする方がはるかに悪いです。

また、メインの文字列を.poファイルなどに保存し、それらにローカリゼーションフレームワークを使用します。これはどちらでもありません。

于 2013-03-24T13:13:14.510 に答える