「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

興味深い部分に分かれます：

1. latin1 サーバーに文字セットラテン1、基本的にはASCIIを使用して文字列を処理させます
2. CP1 コードページ1252の略
3. CI 大文字と小文字を区別しない比較なので、「ABC」は「abc」と等しくなります。
4. AS アクセントが区別されるため、「ü」は「u」と等しくありません。

PS詳細については、@ solomon-rutzkyの回答を必ずお読みください。

受け入れられた回答は少し不完全であることに注意してください。はい、最も基本的なレベルでは、照合は並べ替えを処理します。ただし、選択した照合で定義された比較ルールは、ユーザーデータに対するユーザークエリ以外の多くの場所で使用されます。

「どうCOLLATE SQL_Latin1_General_CP1_CI_ASする？」の場合 「のCOLLATE条項は何をCREATE DATABASEするのか」という意味です。

ステートメントのCOLLATE {collation_name}句は、サーバーではなくデータベースのCREATE DATABASEデフォルトの照合を指定します。データベースレベルとサーバーレベルの既定の照合順序は、異なるものを制御します。

サーバー（インスタンス）レベルのコントロール：

• データベース・レベルのシステム・データベースの照合：master、model、msdb、とtempdb。
• のDBレベルの照合順序を制御するためtempdb、一時変数（グローバルおよびローカル）の文字列列のデフォルトの照合順序になりますが、テーブル変数ではありません。
• のDBレベルの照合順序を制御するため、データベース名（つまりの列）、ログイン名など、サーバーレベルのデータにmaster使用される照合順序になります。namesys.databases
• パラメータ/変数名の取り扱い
• カーソル名の処理
• GOTOラベルの取り扱い
• COLLATE句がない場合に新しく作成されたデータベースに使用されるデフォルトの照合

データベースレベルのコントロール：

• 照合順序は、新しく作成された文字列の列のために使用されるデフォルト（CHAR、VARCHAR、NCHAR、NVARCHAR、TEXT、とNTEXT-しかし、使用していないTEXTかNTEXT）ときCOLLATE句が列定義から欠落しています。これはCREATE TABLEとALTER TABLE ... ADDステートメントの両方に当てはまります。
• 文字列リテラル（つまり'some text'）と文字列変数（つまり@StringVariable）に使用されるデフォルトの照合順序。この照合順序は、文字列と変数を他の文字列と変数と比較するときにのみ使用されます。文字列/変数を列と比較する場合、列の照合順序が使用されます。
• オブジェクト名（つまり）、列名（つまり）、インデックス名（つまり）など、データベースレベルのメタデータに使用される照合順序sys.objectssys.columnssys.indexes
• データベースレベルのオブジェクトに使用される照合順序：テーブル、列、インデックスなど。

また：

• ASCIIは8ビットのエンコードです（一般的な使用法。技術的には「ASCII」は7ビットの文字値0〜127、「ASCII拡張」は8ビットの文字値0〜255）。このグループは、文化を超えて同じです。
• コードページは、拡張ASCIIの「拡張」部分であり、128〜255の値に使用される文字を制御します。このグループは、各カルチャ間で異なります。
• Latin1標準のASCIIは値0〜127のみをカバーし、すべてのコードページ（SQL Serverで表現でき、さらには）がこれらの同じ128の値を同じ文字にマップするため、「ASCII」を意味しません。NVARCHAR

「何をしCOLLATE SQL_Latin1_General_CP1_CI_ASますか？」「この特定の照合順序は何をするのか」を意味し、次に：

• 名前はで始まるためSQL_、これはSQL Server照合順序であり、Windows照合順序ではありません。これらは正式に廃止されなくても、絶対に時代遅れであり、主にSQL Server 2000以前の互換性のためです。ただし、SQL_Latin1_General_CP1_CI_AS言語として米国英語を使用するOSにインストールする場合のデフォルトであるため、残念ながら非常に一般的です。これらの照合は、可能な限り回避する必要があります。

  Windowsの照合順序（名前がで始まっていないものSQL_）はより新しく、より機能的であり、同じ値間VARCHARでソートが一貫しておりNVARCHAR、追加/修正されたソートの重みと大文字/小文字のマッピングで更新されています。これらの照合順序には、SQL Server照合順序のような潜在的なパフォーマンスの問題もありません。VARCHAR型とNVARCHAR型を混合した場合のインデックスへの影響。

• Latin1_General カルチャ/ロケールです。
  • およびデータこれは、ソートと比較のために使用される言語的ルールを決定します。NCHARNVARCHARNTEXT
  • 以下のためCHAR、VARCHARおよびTEXTデータ（列、リテラル、および変数）これが決定されます。
    • ソートと比較に使用される言語規則。
    • 文字のエンコードに使用されるコードページ。たとえば、Latin1_General照合順序はコードページ1252をHebrew使用し、照合順序はコードページ1255を使用します。

• CP{code_page} または {version}

  • 以下のためにSQL Serverの照合順序：CP{code_page}-以上作成するために2バイトの組み合わせを使用することができますダブルバイト文字セット（DBCS）のための4つのコード・ページがありますが255、文字が値128にマッピングするものを決定する8ビットのコードページです256文字。これらはSQL Server照合順序では使用できません。

  • 以下のためのWindows照合順序：{version}、すべての照合名に存在しない一方で、照合が（ほとんどの部分で）導入されたSQL Serverのバージョンを指します。名前にバージョン番号がないWindows照合順序はバージョンです80（SQL Server 2000はバージョン8.0であるため）。SQL Serverのすべてのバージョンに新しい照合順序が付属しているわけではないため、バージョン番号にギャップがあります。一部90（SQL Server 2005、バージョン9.0）、ほとんど100（SQL Server 2008、バージョン10.0）、および小さなセット140（SQL Server 2017、バージョン14.0）があります。

    末尾の照合_SCがSQL Server 2012（バージョン11.0）で導入されたため、「ほとんどの場合」と言いましたが、基礎となるデータは新しいものではなく、組み込み関数の補助文字のサポートを追加しただけです。したがって、これらの末尾はバージョン90と100照合順序に存在しますが、SQL Server 2012でのみ開始されます。

• 次に、次の任意の組み合わせで指定できる感度がありますが、常にこの順序で指定されます。
  • CS=大文字と小文字を区別する、またはCI=大文字と小文字を区別しない
  • AS=アクセントを区別するかAI=アクセントを区別しない
  • KS =かなのタイプ依存または欠落=かなのタイプ非依存
  • WS =幅に依存または欠落=幅に依存しない
  • VSS =バリエーションセレクター依存（バージョン140照合でのみ使用可能）または欠落=バリエーションセレクター非依存

• オプションの最後の部分：

  • _SC末尾の「補足文字サポート」を意味します。「サポート」は、組み込み関数がサロゲートペアを解釈する方法にのみ影響します（これは、補助文字がUTF-16でエンコードされる方法です）。なし_SC末尾に（あるいは_140_中央）、組み込み関数、単一の補助文字を参照して、代わりにサロゲートペアを構成する2つの意味のないコード・ポイントが表示されません。このエンディングは、非バイナリのバージョン90または100照合に追加できます。
  • _BINまたは_BIN2最後に「バイナリ」ソートと比較を意味します。データは同じように保存されますが、言語規則はありません。このエンディングは、5つの感性またはと組み合わせることはありません_SC。_BIN古いスタイルであり_BIN2、新しい、より正確なスタイルです。SQL Server 2005以降を使用している場合は、を使用します_BIN2。間の違いの詳細について_BINと_BIN2、参照してください。各種バイナリ照合順序の違い（文化、バージョン、およびBIN2対BIN）を。

  • _UTF8はSQL Server 2019の新しいオプションです。これは、UnicodeデータをVARCHARとCHARデータ型に格納できるようにする8ビットエンコーディングです（ただし、非推奨のTEXTデータ型ではありません）。このオプションは、補助文字をサポートする照合（つまり_SC、名前にバージョン90または100の照合があり、バージョン140照合）でのみ使用できます。単一のバイナリ_UTF8照合もあります（_BIN2ではなく_BIN）。

    注意： UTF-8は、8ビットエンコーディング用に設定され、Unicodeをサポートしたい環境/コードとの互換性のために設計/作成されました。UTF-8がと比較して最大50％のスペース節約を提供できるいくつかのシナリオがありますがNVARCHAR、それは副作用であり、多くの/ほとんどの操作でパフォーマンスにわずかな影響を与えるコストがあります。互換性のためにこれが必要な場合、コストは許容範囲です。スペースを節約するためにこれが必要な場合は、より良いテストを行い、もう一度テストしてください。テストにはすべての機能が含まれ、数行以上のデータが含まれます。UTF-8照合は、すべての列とデータベース自体がVARCHARデータ（列、変数、文字列リテラル）を_UTF8照合。これは互換性のためにこれを使用するすべての人にとって自然な状態ですが、省スペースのためにそれを使用することを望む人にとってはそうではありません。奇妙な動作/データ損失が発生する可能性があるため、_UTF8照合を使用するVARCHARデータをVARCHAR非_UTF8照合を使用するデータまたはNVARCHARデータと混在させる場合は注意してください。新しいUTF-8照合の詳細については、次を参照してください：SQL Server 2019でのネイティブUTF-8サポート：救世主か偽預言者か？

CP1は「コードページ1」を意味します-技術的には、これはコードページ1252に変換されます

COLLATEは、あなたが文字列値に使用している文字セットとルール（順序、対決ルール）のようなものかを指定するキーワード。

たとえば、あなたのケースでは、大文字と小文字を区別しない（CI）とアクセントを区別する（AS）のラテン規則を使用しています。

このドキュメントを参照できます

これは、データベースのデフォルトの照合を指定します。データベースのテーブルに作成するすべてのテキストフィールドは、別のテキストフィールドを指定しない限り、その照合順序を使用します。

データベースには常にデフォルトの照合があります。何も指定しない場合、SQL Serverインスタンスのデフォルトの照合が使用されます。

使用する照合の名前は、Latin1コードページ1を使用することを示しており、大文字と小文字が区別されず（CI）、アクセントに区別されます（AS）。この照合は米国で使用されるため、米国で使用される並べ替え規則が含まれます。

照合順序は、テキスト値の同等性と類似性の比較方法、および並べ替え時にそれらを比較する方法を決定します。コードページは、varcharフィールドなどの非Unicodeデータを格納するときに使用されます。