「COLLATE SQL_Latin1_General_CP1_CI_AS」は何をしますか？
以下に示すように、SQLServerにデータベースを作成するSQLクエリがあります。
create database yourdb
on
( name = 'yourdb_dat',
filename = 'c:\program files\Microsoft sql server\mssql.1\mssql\data\yourdbdat.mdf',
size = 25mb,
maxsize = 1500mb,
filegrowth = 10mb )
log on
( name = 'yourdb_log',
filename = 'c:\program files\Microsoft sql server\mssql.1\mssql\data\yourdblog.ldf',
size = 7mb,
maxsize = 375mb,
filegrowth = 10mb )
COLLATE SQL_Latin1_General_CP1_CI_AS;
go
正常に動作します。
SQLの残りの部分は明らかですが、COLLATE SQL_Latin1_General_CP1_CI_ASの機能についてはかなり混乱しています。
誰も私にこれを説明できますか？また、この方法でデータベースを作成することがベストプラクティスであるかどうかを知りたいですか？
データベースサーバーのソート方法を設定します。この場合：
SQL_Latin1_General_CP1_CI_AS
興味深い部分に分割されます。
latin1は、サーバーが文字セットlatin 1、基本的にasciiを使用して文字列を処理するようにしますCP1はコードページ1252を表しますCI大文字と小文字を区別しない比較なので、「ABC」は「abc」と等しくなりますASアクセントが区別されるため、「ü」は「u」と等しくありません
P.S。詳細については、 @ solomon-rutzkyの答えを読んでください を確認してください。
受け入れられた答えは少し不完全であることに注意してください。はい、最も基本的なレベルでは、照合がソートを処理します。ただし、選択した照合によって定義された比較ルールは、ユーザーデータに対するユーザークエリ以外の多くの場所で使用されます。
「COLLATE SQL_Latin1_General_CP1_CI_ASの機能」 「CREATE DATABASEのCOLLATE句は何をするのですか？」
COLLATE {collation_name}ステートメントのCREATE DATABASE節は、データベースおよびnotのデフォルト照合を指定します。データベースレベルとサーバーレベルの既定の照合順序は、さまざまなことを制御します。
サーバー（インスタンス）-levelコントロール：
- システムデータベースのデータベースレベルの照合：
master、model、msdb、およびtempdb。 tempdbのDBレベルの照合を制御するため、一時変数（グローバルおよびローカル）の文字列列のデフォルト照合ですが、テーブル変数ではありません。masterのDBレベルの照合を制御するため、データベース名（sys.databasesのname列）、ログイン名などのサーバーレベルデータに使用される照合です。- パラメータ/変数名の処理
- カーソル名の処理
GOTOラベルの処理COLLATE句がない場合に新しく作成されたデータベースに使用されるデフォルトの照合
データベースレベルコントロール：
CHAR句が列定義にない場合、新しく作成された文字列列（VARCHAR、NCHAR、NVARCHAR、TEXT、NTEXT、およびTEXTに使用されるデフォルトの照合順序。ただし、NTEXTまたはCOLLATEは使用しないでください）これはCREATE TABLEおよびALTER TABLE ... ADDステートメントの両方に当てはまります。- 文字列リテラル（
'some text'）および文字列変数（@StringVariable）に使用されるデフォルトの照合。この照合は、文字列と変数を他の文字列と変数と比較するときにのみ使用されます。文字列/変数を列と比較する場合、列の照合が使用されます。 - データベースレベルメタデータに使用される照合。オブジェクト名（つまり
sys.objects）、列名（つまりsys.columns）、インデックス名（つまりsys.indexes）など。 - データベースレベルオブジェクトに使用される照合：テーブル、列、インデックスなど。
また：
- ASCIIは8ビットのエンコードです（一般的な用途では、技術的に「ASCII」は文字値0〜127の7ビットで、「ASCII拡張」は文字値0〜255の8ビットです）。このグループは文化を超えて同じです。
- コードページは、拡張ASCIIの「拡張」部分であり、値128〜255に使用する文字を制御します。このグループは、カルチャごとに異なります。
Latin1はnotは "ASCII"を意味します。標準ASCIIは0〜127の値のみを対象とするため、およびallコードページ（SQL ServerNVARCHAR）これらの同じ128個の値を同じ文字にマップします。
「COLLATE SQL_Latin1_General_CP1_CI_ASの機能」 「この特定の照合は何をするのか？」を意味し、その後：
名前は
SQL_で始まるため、これはWindows照合ではなくSQL Server照合です。これらは、公式に廃止されていなくても、完全に廃止されており、主にSQL Server 2000以前の互換性のためです。ただし、残念ながらSQL_Latin1_General_CP1_CI_ASは、言語として米国英語を使用するOSにインストールする場合のデフォルトであるため、非常に一般的です。これらの照合は、可能な限り回避する必要があります。Windows照合（名前がnotが
SQL_で始まるもの）はより新しく、より機能的で、同じ値に対してVARCHARとNVARCHARの間で一貫したソートがあり、追加/修正されたソートの重みと大文字/小文字で更新されていますマッピング。これらの照合には、SQL Server照合の潜在的なパフォーマンスの問題もありません。 VARCHAR型とNVARCHAR型を混合した場合のインデックスへの影響 。Latin1_Generalはカルチャ/ロケールです。NCHAR、NVARCHAR、およびNTEXTデータの場合、これはソートおよび比較に使用される言語規則を決定します。CHAR、VARCHAR、およびTEXTデータ（列、リテラル、および変数）の場合、これにより以下が決まります。- ソートおよび比較に使用される言語規則。
- 文字のエンコードに使用されるコードページ。たとえば、
Latin1_General照合はコードページ1252を使用し、Hebrew照合はコードページ1255を使用します。
CP{code_page}または{version}- SQL Server collations：
CP{code_page}は、128〜255の値にマップする文字を決定する8ビットコードページです。2バイト文字セット（DBCS）には、使用できる4つのコードページがあります。 256文字を超える2バイトの組み合わせは、SQL Server照合では使用できません。 Windows collationsの場合：
{version}は、すべての照合名に存在するわけではありませんが、照合が導入されたSQL Serverバージョンを指します（ほとんどの場合）。名前にバージョン番号のないWindows照合順序は、バージョン80です（つまり、SQL Server 2000はバージョン8.0です）。 SQL Serverのすべてのバージョンに新しい照合順序が付属しているわけではないため、バージョン番号にギャップがあります。90（バージョン9.0のSQL Server 2005の場合）、ほとんどが100（SQL Server 2008、バージョン10.0の場合）、および小さなセットに140（SQL Server 2017、バージョン14.0の場合）があります。_SCで終わる照合順序がSQL Server 2012（バージョン11.0）で導入されたため、「大部分」と言いましたが、基礎となるデータは新しいものではなく、組み込み関数の補助文字のサポートを追加しただけです。そのため、バージョン90および100照合にはこれらの末尾が存在しますが、SQL Server 2012でのみ開始されます。
- SQL Server collations：
- 次に、感度があります。これは、次の任意の組み合わせにすることができますが、常にこの順序で指定されます。
CS=大文字と小文字を区別する、またはCI=大文字と小文字を区別しないAS=アクセントを区別する、またはAI=アクセントを区別しないKS=かなタイプ非対応または欠落=かなタイプ非対応WS= width-sensitiveまたはmissing = width insensitiveVSS=バリエーションセレクター依存（バージョン140照合でのみ使用可能）または欠落=バリエーションセレクター非依存
オプションの最後のピース：
- 最後の
_SCは「補助文字のサポート」を意味します。 「サポート」は、組み込み関数がサロゲートペアを解釈する方法（補助文字がUTF-16でエンコードされる方法）にのみ影響します。末尾に_SC（または中央に_140_）がない場合、組み込み関数は単一の補助文字を表示しませんが、代わりにサロゲートペアを構成する2つの無意味なコードポイントを表示します。この末尾は、バイナリ以外のバージョン90または100の照合に追加できます。 - 最後の
_BINまたは_BIN2は、「バイナリ」ソートと比較を意味します。データは同じように保存されますが、言語規則はありません。この結末は、5つの感度または_SCのいずれとも組み合わせられません。_BINは古いスタイルで、_BIN2は新しい、より正確なスタイルです。 SQL Server 2005以降を使用している場合は、_BIN2を使用します。_BINと_BIN2の違いの詳細については、 さまざまなバイナリ照合順序（文化、バージョン、およびBIN対BIN2）の違い を参照してください。 _UTF8は、SQL Server 2019の新しいオプションです。UnicodeデータをVARCHARおよびCHARデータ型（非推奨のTEXTデータ型ではない）に格納できる8ビットエンコーディングです。このオプションは、補助文字をサポートする照合（つまり、名前に_SCを含むバージョン90または100の照合、およびバージョン140の照合）でのみ使用できます。単一のバイナリ_UTF8照合もあります（_BIN2ではなく、_BIN）。注意：UTF-8は、環境との互換性のために設計/作成されたものであり、8ビットエンコード用にセットアップされているがUnicodeをサポートしたいコードです。
NVARCHARと比較してUTF-8が最大50％のスペース節約を提供できるシナリオはいくつかありますが、これは副作用であり、多くの/ほとんどの操作でパフォーマンスにわずかな打撃を与えます。互換性のためにこれが必要な場合、コストは許容できます。スペースを節約するためにこれが必要な場合は、より良いテストを行い、もう一度テストしてください。テストには、すべての機能と、数行以上のデータが含まれます。 UTF-8照合は、すべての列とデータベース自体が_UTF8照合でVARCHARデータ（列、変数、文字列リテラル）を使用しているときに最適に機能することに注意してください。これは互換性のためにこれを使用する人にとっては自然な状態ですが、スペース節約のために使用したい人にとってはそうではありません。_UTF8照合を使用するVARCHARデータと、__UTF8照合を使用するVARCHARデータまたはNVARCHARデータを混在させる場合は、奇妙な動作/データ損失が発生する可能性があるため、注意してください。新しいUTF-8照合の詳細については、以下を参照してください： SQL Server 2019でのネイティブUTF-8サポート：救い主または偽預言者？
- 最後の
CP1は「コードページ1」を意味します-技術的には、これはコードページ1252に変換されます
COLLATEキーワードは、文字列値に使用する文字セットとルール（順序、対立ルール）の種類を指定します。
たとえば、大文字と小文字を区別しない（CI）とアクセントを区別する（）のラテン語ルールを使用している場合_）として
これを参照できます ドキュメント
これは、データベースのデフォルトの照合を指定します。別のフィールドを指定しない限り、データベースのテーブルに作成したすべてのテキストフィールドはその照合を使用します。
データベースには常にデフォルトの照合があります。何も指定しない場合、SQL Serverインスタンスのデフォルトの照合が使用されます。
使用する照合の名前は、Latin1コードページ1を使用し、大文字と小文字を区別しない（CI）とアクセントを区別する（AS）ことを示しています。この照合は米国で使用されるため、米国で使用されるソート規則が含まれます。
照合は、テキスト値の等価性と類似性の比較方法、およびソート時の比較方法を決定します。コードページは、Unicode以外のデータを保存するときに使用されます。 varcharフィールド。