多言語ユーザーインターフェイスの背後にあるデータベース
この質問は、これらの古い質問ですでに対処されている問題よりも少し複雑な問題に関するもので、すべてが互いに重複しています。 多言語のデータベース構造の提案（2011年6月） 多言語データを保持するのに最適なデータベース構造は何ですか？（2010年2月） 多言語データベース設計のベストプラクティスは何ですか？（2009年5月） 多言語データベースのスキーマ（2008年11月） 多言語ユーザーインターフェイスをサポートする最も一般的なデータベーススキームは、すべての言語のすべての翻訳テキストを、テキストID、言語コード、およびテキスト自体の3つの列を持つ1つのテーブルに格納することです。テキストIDと言語コードが一緒になって主キーを構成します。 これで問題ありませんが、ここで複雑さを考えてみましょう。テキストが検索可能である必要があるとします。たとえば、これが多言語のeショップであるとします。つまり、データベースに入力されたすべての製品カテゴリについて、ショップの所有者は、サポートされているN言語のそれぞれに製品カテゴリの名前を入力し、買い物客は名前で製品カテゴリを検索できます。母国語で。 問題があります：照合順序。 言語によって照合順序は異なり、ある言語で機能する照合順序は別の言語では機能しません。それで、すべての言語のすべてのテキストが1つの列にある場合、どのような照合順序になりますか？特定のテキストのテキストIDを見つけるために、データベースにどのようにクエリするのでしょうか。Web製品では、検索の正確さとパフォーマンスはそれほど重要ではないかもしれませんが、この説明では、それらが本当に重要であると仮定します。 ほとんどのデータベース管理者は、「データベースの照合」という意味で照合の概念に精通しています。幸い、これは単なるデフォルトの照合であり、他の照合情報が存在しない場合に使用されますが、照合を指定できる場所が他にもあります。 SQL CREATE INDEXコマンドは、照合指定をサポートしています。（Microsoft SQL Serverがサポートしていないという噂はありますが、それについて誰か知っていますか？） SQL SELECTステートメントも照合をサポートしますが、この場合、照合仕様は関数として機能し、インデックスルックアップの代わりにインデックススキャンを引き起こします。これは、パフォーマンスが必要な場合は許容できない可能性があります。（それでも、それが私たちが持つことができる最高の場合、何もないよりはましかもしれません。） また、Microsoft SQL Serverでは、照合を指定してフィルター処理されたインデックスを作成できる非永続的な計算列を使用できると聞いていますが、これは聞いたことがなく、Microsoft-SQL-Serverのみの場合は機能については、それがどれほどクールでよく考えられていても、使用を控えたいと思います。 では、これらすべてを踏まえて、更新可能で検索可能な多言語データベースが目標である場合、データベースをどのように構成し、クエリをどのように実行するのでしょうか。 この質問は、ここで行われた議論に触発されました。nvarchar（max）がデータベースにデータを格納する方法は、一部のデータが4000文字未満の場合、どのように高速になるでしょうか。