要約
DB設計時に忘れがちな「照合順序」は、後から変更するのがほぼ不可能な、非常に重要な設定です。
この設定を間違えると、データの検索や結合で予期せぬエラーが発生し、大きな手戻りの原因となります。
本記事では、照合順序の基本から実践的な調査方法、そして実際の現場で注意すべき点までを分かりやすく解説します。
はじめに
データベース設計というと、テーブル定義やデータ型に目が行きがちですが、実はもう一つ、最初に決めておかないと後で”詰む”設定があります。それが 「照合順序（Collation）」 です。
「照合順序」とは？
一言でいうと、データベース内での「文字の扱い方のルール のことです。具体的には、以下のようなことを定義しています。
- 大文字と小文字を区別するか？ (例: 'A' と 'a' は同じ？違う？)
- 全角と半角を区別するか？ (例: 'ｱ' と 'ア' は同じ？違う？)
- ひらがなとカタカナを区別するか？ (例: 'あ' と 'ア' は同じ？違う？)
- 文字を並べ替える（ソートする）ときの順番
なぜそんなに重要？「後から変更できない」からです！
照合順序が重要な最大の理由は、**「データベース作成後に変更するのが、ほぼ不可能に近い」**からです。
もし照合順序を間違えてしまうと、アプリケーションで次のような不具合が発生する可能性があります。
-
WHERE句で検索しても、期待したデータがヒットしない。 -
ORDER BYで並べ替えたら、五十音順にならない。 -
JOINでテーブルを結合するキーが、うまく一致しない。
これらの問題を後から修正するには、全データをエクスポートし、データベースを作り直し、データを再インポートする...という非常に大規模な作業が必要になります。だからこそ、最初の設計段階で正しく設定することが不可欠なのです。
私たちはどうすればいい？
対応は2つのパターンに分かれます。新しいDBを作るのか、既存のDBを引き継ぐのかでやるべきことが変わります。
パターン1：新しいデータベースを設計する場合
アプリケーションの要件をしっかり確認し、最適な照合順序を最初に決定します。
- 要件定義: ユーザーのデータをどう扱うか（大文字/小文字を区別するか等）を決めます。
-
選択: 日本語環境のSQL Serverでは、一般的に
Japanese_CI_ASが選ばれます。-
CI: Case-Insensitive (大文字/小文字を区別しない) -
AS: Accent-Sensitive (アクセント記号を区別する)
-
- 記録: 決定した照合順序を必ず設計書に明記します。
パターン2：既存のデータベースを移行・改修する場合
「今の設定」がどうなっているかを正確に調査し、それを引き継ぐのが基本です。勝手に変えてはいけません。
【確認用SQL】
以下のSQLを実行して、現在の設定を確認しましょう。
① サーバー全体の照合順序を確認
SELECT SERVERPROPERTY('collation') AS ServerCollation;
② データベースごとの照合順序を確認
SELECT name, collation_name FROM sys.databases;
調査結果を、こちらも必ず設計書に明記してください。これが未来の自分やチームを助けることになります。
【実践編】実際の調査レポートから学ぶ注意事項
理論だけでなく、実際の調査レポートからどんな点に注意すべきかを見てみましょう。以下は、あるサーバーの調査結果の抜粋です。
ServerCollation: Japanese_CI_AS
name collation_name
----------------- ------------------
CUSTOMER_DB Japanese_CI_AS
PRODUCT_DB Japanese_CI_AS
... ...
SOME_LEGACY_DB Japanese_BIN
... ...
SALES_DB Japanese_CI_AS
【最重要注意点】一つだけ違う「仲間外れ」がいないか？
このレポートから分かる最も重要なことは、SOME_LEGACY_DB というデータベースだけ照合順序が Japanese_BIN になっている点です。他はすべて Japanese_CI_AS です。
- Japanese_CI_AS: 大文字・小文字を区別しない、日本語環境の標準的な設定。
- Japanese_BIN: 文字のバイナリコードで比較するため、大文字・小文字を厳密に区別する。
なぜこれが問題になるのか？
もし、Japanese_CI_AS のDBと Japanese_BIN のDBをまたいで、文字型の列でデータを結合（JOIN）しようとすると、SQL Serverはルールが違うため比較できず、以下のようなエラーを返します。
Cannot resolve the collation conflict between "Japanese_BIN" and "Japanese_CI_AS" in the equal to operation.
これは「照合順序が違うから比較できません！」というエラーです。これに気づかずに開発を進めると、後で大きな手戻りが発生する原因になります。
このように、「ほとんどが同じでも、一部に例外がないか」 という視点でレポートを確認することが、トラブルを未然に防ぐ鍵となります。例外を見つけたら、そのDBがなぜ違う設定になっているのか、どんな影響があるのかを必ず設計書に特記しましょう。
まとめ
照合順序で失敗しないためのルールは、とてもシンプルです。
-
新規DBは「最初に決めて、書く」
- 要件に合わせて最初に決め、設計書に必ず明記する。
-
既存DBは「調べて、書く」
- 現状を正確に調査し、例外も含めて設計書に必ず明記する。
この小さな一手間が、将来の大きなトラブルを防ぎます。しっかり覚えておきましょう！