エンコーディングの選択を可能にする他のRDBMSとは異なり、SQLServerはUnicodeデータのみを保存します。 UTF-16（リトルエンディアン）、およびフィールドの照合によって暗示されるコードページに対応する8ビットエンコーディング（拡張ASCII、DBCS、またはEBCDIC）の非Unicodeデータ。
選択するという彼らの決定 UCS-2は、UTF-16が1996年半ばに導入され、2000年に完全に指定されたことを考えると、十分に理にかなっています。他の多くのシステムでもUTF-16が使用（または使用）されています（ https://en.wikipedia.org/wiki/UTF-16#Usage ）。 続行するという彼らの決定 おそらくWindowsと.NETがUTF-16であることが原因ですが、それはもっと疑わしいかもしれません。バイトの物理レイアウトはUCS-2とUTF-16で同じであるため、システムをUCS-2からアップグレードしてUTF-16をサポートすることは、既存のデータを変更することなく、純粋に機能する必要があります。
いいえ。 SQLCLRを介してカスタムユーザー定義型を作成することはではありません 、とにかく、ネイティブタイプの代わりになります。特殊なデータを処理するものを作成するのに非常に便利です。しかし、文字列は、エンコードが異なっていても、特殊化されているとは言えません。文字列データに対してこのルートを使用すると、システムの使いやすさが損なわれ、パフォーマンスは言うまでもなく、を使用できなくなります。 組み込みの文字列関数。ディスクスペースに何かを節約できた場合、それらの利益は、全体的なパフォーマンスで失われるものによって消去されます。 UDTの保存は、UDTをVARBINARYにシリアル化することで実行されます。 。だから何かをするために 文字列の比較または並べ替え、「バイナリ」/「序数」の比較以外では、他のすべての値を1つずつUTF-8に変換して、言語の違いを説明できる文字列比較を実行する必要があります。
また、その「ドキュメント」は、実際には単なるサンプルコード/概念実証です。コードは2003年に作成されました（ http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ）SQL Server 2005の場合。機能をテストするスクリプトを見ましたが、パフォーマンスには関係ありません。
はい、とてもそうです。デフォルトでは、組み込み関数の処理はUCS-2専用です。ただし、SQL Server 2012以降では、次のいずれかの照合を使用して、完全なUTF-16文字セット（OSと.NET Frameworkのバージョンに応じてUnicodeバージョン5または6以降）を処理できるようになります。名前が_SCで終わる （つまり、補足文字）。
正しい。 UTF-16とUCS-2はどちらも2バイトのコードポイントを使用します。ただし、UTF-16は、それらの一部をペア（つまり、サロゲートペア）で使用して、追加の文字をマップします。これらのペアに使用されるコードポイントは、UCS-2でこの目的のために予約されているため、使用可能なシンボルへのマッピングには使用されません。これが、SQL Serverに任意のUnicode文字を格納でき、正しく格納および取得される理由です。
誤解を招くかもしれませんが、正解です。はい、UTF-8は可変幅ですが、すべての補助文字が2つの2バイトコードポイントで構成されているため、UTF-16もわずかに可変です。したがって、UCS-2は常に2バイトですが、UTF-16はシンボルごとに2バイトまたは4バイトを使用します。しかし、それは誤解を招く部分ではありません。誤解を招くのは、他のUnicodeエンコーディングでは他のすべてのコードポイントをエンコードできないという意味です。 UCS-2はそれらを保持できますが、それらを解釈することはできませんが、UTF-16とUTF-32はどちらも、UTF-8と同様に、すべてのUnicodeコードポイントをマップできます。
これは本当かもしれませんが、運用の観点からはまったく関係ありません。
繰り返しになりますが、UTF-16とUTF-32もすべてのUnicodeコードポイントをマップするため、真ですが、まったく関係ありません。
状況によっては、これは非常によく当てはまる可能性があり、そのような無駄な使用法について心配するのは正しいことです。ただし、これにつながる質問で述べたように（ UTF-8サポート、SQLServer2012およびUTF8StringUDT
）、ほとんどの行がVARCHARに収まる場合に無駄になるスペースの量を軽減するために、いくつかのオプションがあります。 ただし、一部はNVARCHARである必要があります 。最良のオプションは、行圧縮またはページ圧縮を有効にすることです（Enterprise Editonのみ！）。 SQL Server 2008 R2以降では、非MAX NVARCHARが許可されています。 少なくともUTF-8と同等であり、場合によってはUTF-8よりも優れている「Unicodeの標準圧縮スキーム」を使用するフィールド。 NVARCHAR(MAX) フィールドはこの派手な圧縮を使用できません 、ただし、それらのIN ROWデータは、通常のROWおよび/またはPAGE圧縮の恩恵を受けることができます。この圧縮の説明と、データ圧縮が有効になっている未加工のUCS-2 / UTF-16、UTF-8、およびUCS-2 /UTF-16のデータサイズを比較するグラフについては、以下を参照してください。
SQL Server2008R2-UCS2圧縮とは-SAPシステムへの影響
データ圧縮 についてはMSDNページも参照してください。 いくつかの制限があるため、詳細については（Enterprise Editionでのみ利用可能である以外に、すべてで利用可能になっています） SQL Server 2016、SP1以降のエディション!!）および圧縮によって状況が悪化する可能性がある状況。
そのステートメントの信憑性は、「ディスク」をどのように定義するかによって異なります。デスクトップ/ラップトップで使用するために店ですぐに購入できる商品部品に関して話しているなら、確かに。ただし、本番システムで使用されるエンタープライズレベルのストレージに関して言えば、予算を管理している人に、「安価」であるために必要な100万ドル以上のSANを拒否してはならないことを説明して楽しんでください。 ";-)。
私が考えることができるものはありません。ええと、そのUDTを実装したり、すべての文字列をVARBINARYに変換したりするような恐ろしいアドバイスに従わない限り、 、またはNVARCHAR(MAX)を使用する すべての文字列フィールドに対して;-)。しかし、心配する可能性のあるすべてのことの中で、UCS-2/UTF-16を使用するSQLServerはそれらの1つであってはなりません。
ただし、何らかの理由でUTF-8のネイティブサポートがないというこの問題が非常に重要な場合は、UTF-8を使用できる別のRDBMSを見つける必要があるかもしれません。
更新2018-10-02
これはまだ実行可能なオプションではありませんが、SQLServer2019ではVARCHARでUTF-8のネイティブサポートが導入されています / CHAR データ型。現在、バグが多すぎて使用できませんが、修正されている場合、これは一部のオプションです。 シナリオ。私の投稿「