これが以前に尋ねられた場合はお詫びします。徹底的に検索した後、解決策として役立つものを見つけることができません(同様の答えが以下に掲載されています)。 これは、私が知らないことを知らないというだけの理由で、自由回答型(幅広い)質問だと思います。このサイトに適さない場合は投票しないでください。代わりに、正しい方向のいくつかのポインタが高く評価されます。
ASP.Netを備えたSQL Server 2012で実行されているWebアプリケーションがあります。約150のテーブルと600のストアドプロシージャがあります。幸いなことに、各クライアントは自分の言語でのみデータを必要としたため、歴史的に3つの異なる言語にわたるデータを管理することに成功しています。
例えば:
現在、20の言語で利用できるグローバルデータベースデータの標準セットを必要とする見込み顧客がいます。インターフェイスの変換は(大きな仕事ですが)技術的に難しくはありませんが、SQL Serverでこれがどのように実現されるかを理解するのに苦労しています。 OracleやSAPなどのエンタープライズレベルの企業が定期的にこれを行う必要があることを考えると(私はそう思います)、それは何らかの形で可能であると確信しています。
A 関連する回答 、MySQLは実行可能であるようですが...
通常、2つのテーブルを使用します。対応する値を翻訳テーブルに追加するのを忘れた場合に備えて、メインテーブルにはデフォルトの言語があります。
create table books ( book_id int, book_name varchar(200), description varchar(500) ) create table books_language ( book_id int, language_id vachar(10), book_name varchar(200), description varchar(500) )
これは、デフォルト言語を含むすべてのレコードを返します。
select book_id, isnull(books_language.laguage_id, 'default') isnull(books_language.name, books.name) as name, isnull(books_language.description, books.description) as description from books left join books_language on books.book_id = books_language.book_id
...しかし、データベースのサイズが2倍になり、テーブル数が300になるとすると、以下の実用性を理解できません。
それとも完全に良い方法はありますか?
Google TranslatorやBingなどのウィジェットを試しましたが、正常に動作しません。どちらもページの部分的な再読み込みからのデータに苦労していますが、すべてを変換するだけで、多くの場合あまりうまくいきません。プラグインソフトウェアについても読みましたが、これらはOracle専用です。
たとえば、人々のスキルが記録および管理されるスキルデータベースを見てみましょう。 personテーブルは明らかに変換する必要はなく、日付形式(例えば、誕生日)はインターフェース(ブラウザー設定に基づく.Net)によって処理されます。ただし、スキルテーブルはより複雑です。
Id int,
SkillTitle nvarchar(100),
Description nvarchar(max),
Objectives nvarchar(max)
次に、スキルに対する能力を定義する表があります。
Id int,
SkillLevel int,
Title nvarchar(100),
Description nvarchar(max),
ContextualData nvarchar(max)
基本的に私のデータベースには、テキストベースのデータをさまざまな言語で管理する必要がある約70のテーブルがあります。テキスト列がいくつかあるものや、10ものものもあります。
まあ、これの多くは正確にどのデータ要素を翻訳する必要があるかに依存しており、現時点では、本当にニーズがどこにあるのかではなく、技術的な詳細に集中しすぎていると思います。
これを考えると:
ASP.Netはリソースファイルを使用してローカル言語のインターフェイスを提供します
データベースで翻訳する必要がある要素は何ですか?
この構造が必要になるものの例を1つまたは2つ提供できますか?この構造は、リソースファイルを使用していない場合に使用されるものと思われます。
ここで確認できる唯一のグローバリゼーションの問題は、多くの/ほとんどの文字を共有している場合でも、多くの文化には異なるルールがあるため、各ユーザーの優先言語に従って並べ替えと比較を処理する方法です。残念ながら、照合を動的に指定することはできないため、動的SQLを使用する必要があります(これを可能にするために私の提案に投票してください: COLLATE句を使用するときに変数によって設定された照合を許可する(少なくとも式で) ) )。しかし、今のところ(または、その要求が実装される可能性を考えると、おそらく永久に:-()、COLLATE
キーワードをクエリの関連部分に追加する必要があります(WHERE
/GROUP BY
/ORDER BY
/etc)現在のユーザーの言語に基づく。だから一人はFrench_100_CI_AS
と他の誰かがLatin1_General_100_CI_AS
、 等々。これは複数のフィールドを必要としません。
さまざまな言語のさまざまな列で得られる唯一のものは、さまざまな照合順序(つまり、ロケール)にインデックスを付ける機能です。したがって、本当にパフォーマンスを必要とする場所がある場合は、列の照合として1次言語を指定することを検討し、次に、別の照合と一緒にメイン列を返すだけの非永続計算列を作成し、非-永続的な計算列。
リソースファイルで処理されない1つのアイテムに相当する複数の言語をアプリで本当に保存する必要があると思われる場合は、少なくとも2つの例ではなく、少なくとも1つの例を提供してください。しかし、いくつかあるとしても、それがすべて、またはほとんどの場合でも、どのようになるかはわかりません。顧客名のようなものは、彼らがどの言語から来たのかによって変わることはありません。つまり、中学校と高校のスペイン語クラスに私の名前のスペイン語形式を採用しましたが、それはクラス用でした。スペイン語圏の国の企業の顧客になっても、本名をつけます。そして、私の街路、都市、州の名前も変わりません。