MSSQLでは「計算列」という自動で計算してくれる列がある。
たいていは、「単価×数量」の結果を格納する列にそれを設定するのだが、
キーのグルーピングにも応用できそうだ。

以下のような感じ。(主キーの先頭4文字を別キーとする)
┌──────────────────────────────────────┐
│CREATE TABLE [dbo].[表] (                                                   │
│    [キー]                  [int]               NOT NULL,                   │
│    [部分キー]              AS SUBSTRING([キー], 0, 4),                     │
│    CONSTRAINT [主キー] PRIMARY KEY CLUSTERED (                             │
│        [キー]                  ASC                                         │
│    )                                                                       │
│);                                                                          │
├──────────────────────────────────────┤
│CREATE INDEX [索引] ON [dbo].[表] (                                         │
│    [部分キー]                                                              │
│);                                                                          │
└──────────────────────────────────────┘

インデックスも張れるので、都度文字列編集しながらの検索とかが
インデックスを効かせて快適(快速)に行うことができる。
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│    FROM [表]                                                               │
│    WHERE SUBSTRING([キー], 0, 4) = 'XXXX';                                 │
├──────────────────────────────────────┤
│SELECT *                                                                    │
│    FROM [表]                                                               │
│    WHERE [部分キー] = 'XXXX';                                              │
└──────────────────────────────────────┘
これは便利。

なお、「計算列」には直接INSERTできない(エラー)から注意(というか当たり前か)。

以下の二つの案がある

【あらかじめ集計テーブルを作り結合する案】
┌──────────────────────────────────────┐
│SELECT [親表].[キー],                                                       │
│       ISNULL([子表].[件数], 0) AS [件数]                                   │
│    FROM [親表]                                                             │
│        LEFT JOIN (                                                         │
│           SELECT [外部キー],                                               │
│                  COUNT(*)   AS [件数]                                      │
│               FROM [子表]                                                  │
│               GROUP BY [外部キー]                                          │
│        ), 0) AS [子表]                                                     │
│          ON [子表].[外部キー] = [親表].[キー]                              │
└──────────────────────────────────────┘

【副問い合わせにて集計する案】
┌──────────────────────────────────────┐
│SELECT [親表].[キー],                                                       │
│       ISNULL((                                                             │
│           SELECT COUNT(*)                                                  │
│               FROM [子表]                                                  │
│               WHERE [子表].[外部キー] = [親表].[キー]                      │
│       ), 0) AS [件数]                                                      │
│    FROM [親表];                                                            │
└──────────────────────────────────────┘

結果の種類が多い場合は前者が、少ない場合は後者が有利っぽいが、
最適化された結果、そんなに変わらないみたい。
＃一見、後者は毎回集計しそうだが、あらかじめ集計テーブルを作っぽい

コピペという点では後者が有利っぽいが、性能的にはちょっとだけ前者がよさそう。

「SQL Server Management Studio」のクエリにて、実行計画を表示する設定。
┌──────────────────────────────────────┐
│SET STATISTICS PROFILE ON;                                                  │
└──────────────────────────────────────┘
元に戻すには以下の通り。
┌──────────────────────────────────────┐
│SET STATISTICS PROFILE OFF;                                                 │
└──────────────────────────────────────┘

┌──────────────────────────────────────┐
│CREATE VIEW [dbo].[仮想表] WITH SCHEMABINDING                               │
│AS                                                                          │
│    SELECT [列]                                                             │
│        FROM [dbo].[表]                                                     │
│;                                                                           │
├──────────────────────────────────────┤
│CREATE UNIQUE CLUSTERED INDEX [AK_仮想表] ON [dbo].[V_仮想表] (             │
│    [キー]                  ASC                                             │
│);                                                                          │
└──────────────────────────────────────┘
・仮想表作成時に「WITH SCHEMABINDING」をつける
  ・仮想表作成時にDB名を指定しない  ×「[DB].[dbo].[表]」→「[dbo].[表]」
    →つまりは他DBを絡めたビューには指定できないということ
・仮想表の中で参照している元の仮想表にも「WITH SCHEMABINDING」をつける
  →上記ルールが元の仮想表まですべて適用されるということ
・仮想表の中で参照している元の仮想表においては集約関数は使用不可

「秒」を「時分秒」に換算するのに以下を使ってみた。
┌──────────────────────────────────────┐
│SELECT RTRIM(CONVERT(char(12),                                              │
│                     DATEADD(SECOND,                                        │
│                             [秒数],                                        │
│                             CONVERT(datetime, 0)),                         │
│                     108)                                                   │
│       )                                                                    │
└──────────────────────────────────────┘
ところが、24時間(86400秒)を超えると、「日」が繰り上がり「時」が「0」に戻る。
つまり本来「25時間」であるべきところが「(1日と)1時間」になってしまう。

MySQLだったら「SEC_TO_TIME()」という便利な関数があり、
「25時間」もへっちゃらなのだが。
┌──────────────────────────────────────┐
│SELECT SEC_TO_TIME(`秒数`);                                                 │
└──────────────────────────────────────┘

ということで、自前で実装してみた。
┌──────────────────────────────────────┐
│CREATE FUNCTION [dbo].[sec_to_time] (                                       │
│    @引数秒数               int                                             │
│) RETURNS varchar(max)                                                      │
│AS                                                                          │
│BEGIN                                                                       │
│    RETURN (                                                                │
│        SELECT CONVERT(varchar, FLOOR(@引数秒数 / 3600))                    │
│             + RIGHT(                                                       │
│                   RTRIM(CONVERT(char(12),                                  │
│                                 DATEADD(SECOND,                            │
│                                         ABS(@引数秒数),                    │
│                                         CONVERT(datetime, 0)),             │
│                                 108)),                                     │
│               6)                                                           │
│    );                                                                      │
│END;                                                                        │
└──────────────────────────────────────┘

だいたい速い。

結果は同じでも以下の二つの経路があったとする
・レコードを絞り込んで、それについてのみ計算を行う
・全て計算を行った上で、レコードを絞り込む

一つの計算あたり複雑で負荷がかかる場合、断然前者の方が速い。
なんといっても、日の目を見ない計算をハナからやらないのだから。

例えば、その複雑な計算を全件について行う[重いVIEW]というのがあった場合、
必要なデータである[抽出Ｄ]についてだけ結果が欲しいとすると、
単純に以下の様に内部結合を行う。
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│    FROM [重いVIEW]                                                         │
│        INNER JOIN [抽出Ｄ]                                                 │
│          ON [重いVIEW].[キー] = [抽出Ｄ].[キー];                           │
└──────────────────────────────────────┘
この場合、「全て計算してから抽出する」パターンになりがちだ。
(「INNER JOIN」の順番を逆にしても同じ)

WHERE文を明示的に指定する、例えば以下のような場合は
「抽出してから計算する」パターンにもっていきやすい。
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│     FROM [重いVIEW]                                                        │
│     WHERE [キー] = (SELECT TOP 1 [キー] FROM [抽出Ｄ]);                    │
└──────────────────────────────────────┘
ただ、これだと、一件しか対応できない。

で、これを複数件でも耐えうる形にするのが相関副問い合わせだ。
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│    FROM [重いVIEW]                                                         │
│    WHERE EXISTS (                                                          │
│              SELECT *                                                      │
│                  FROM [抽出Ｄ]                                             │
│                  WHERE [抽出Ｄ].[キー] = [重いVIEW].[キー]                 │
│          );                                                                │
└──────────────────────────────────────┘
相関副問い合わせ自体が速いということではないらしいのだが
手続きの順番が抽出優先になるという点で、相関副問い合わせは速く感じる。

つまり、相関副問い合わせは難しげだがマスタすると強力な武器になるということだ。

┌─┬────────────────────────────────────┐
│真│'abc' = 'abc'                                                           │
├─┼────────────────────────────────────┤
│真│'abc' = 'abc '                                                          │
└─┴────────────────────────────────────┘
上記のような場合、後者は「偽」になりそうなものである。

しかしながら、これは(「真」になるのは)、
「ANSI/ISO SQL-92」の立派な規格なのである(比較では後続の空白は無視)。

ということで、データを管理・入力する時は、トリムを推奨しようねという話でした。

では、既に混入済みの場合は、どうやってみつけだすのか？

基本的にバイナリに変換して比較すれば、厳密に比較ができる。
┌─┬────────────────────────────────────┐
│真│CONVERT(binary, 'abc') = CONVERT(binary, 'abc')                         │
├─┼────────────────────────────────────┤
│偽│CONVERT(binary, 'abc') = CONVERT(binary, 'abc ')                        │
└─┴────────────────────────────────────┘

但し、型が違うと(特に「nvarchar」と「varchar」など)、
バイナリ変換される結果も変わってくるので、
念のため以下の様に事前に型を合わせておくというのも検討せねばならない。
┌─┬────────────────────────────────────┐
│真│CONVERT(binary, CONVERT(nvarchar(4000), 'abc'))                         │
│  │                       = CONVERT(binary, CONVERT(nvarchar(4000), 'abc'))│
├─┼────────────────────────────────────┤
│偽│CONVERT(binary, CONVERT(nvarchar(4000), 'abc'))                         │
│  │                      = CONVERT(binary, CONVERT(nvarchar(4000), 'abc '))│
└─┴────────────────────────────────────┘
変換を介するということは処理速度が遅くなので、必要なければ端折るのがよい。

また、以下の様な方法もある(「COLLATE JAPANESE_BIN =」ではないので注意)。
┌─┬────────────────────────────────────┐
│真│'abc' COLLATE JAPANESE_BIN LIKE 'abc'                                   │
├─┼────────────────────────────────────┤
│偽│'abc' COLLATE JAPANESE_BIN LIKE 'abc '                                  │
└─┴────────────────────────────────────┘

┌─┬───────┬─┬─┬──┬─────────────────────┐
│16│vbCritical    │○│×│警告│MsgBox "エラー発生", vbCritical           │
├─┼───────┼─┼─┼──┼─────────────────────┤
│32│vbQuestion    │Ｑ│？│問合│If MsgBox("しますか？", _                 │
│  │              │  │  │    │          vbOKCancel + vbQuestion, _      │
│  │              │  │  │    │          "確認") <> vbOK Then            │
├─┼───────┼─┼─┼──┼─────────────────────┤
│48│vbExclamation │△│！│注意│MsgBox "見直してください", vbExclamation  │
├─┼───────┼─┼─┼──┼─────────────────────┤
│64│vbInformation │Ｑ│ｉ│情報│MsgBox "正常終了", vbInformation          │
└─┴───────┴─┴─┴──┴─────────────────────┘

以下の関数がある(強度の弱い順)。
┌────────┬──────┬────────────┬─────────┐
│   暗号化関数   │ 暗号化結果 │          環境          │     照合手段     │
├────────┼──┬───┼────────────┼─────────┤
│md5()           │固定│32文字│PHP5.3～                │md5()             │
├────────┼──┼───┼────────────┼─────────┤
│crypt()         │可変│34文字│PHP5.3～                │crypt()           │
├────────┼──┼───┼────────────┼─────────┤
│password_hash() │可変│60文字│PHP5.5～(PHP5.3.7～(*1))│password_verify() │
└────────┴──┴───┴────────────┴─────────┘
  *1：標準関数となったのはPHP5.5以降だが、その前に別途ライブラリとしてあった

  ・「md5()」は結果が固定なので解読されるリスクが高い
  ・「crypt()」は「salt」の指定等を自前でチューニングする必要あり
  ・「password_hash()」が簡潔にして強固(現状最適)

使用例は以下のような感じ。
┌────────────────┬─────────────────────┐
│             暗号化             │                   照合                   │
├────────────────┼─────────────────────┤
│$暗号文 = md5($平文);           │if (md5($平文) === $暗号文) {             │
│                                │    echo '○';                            │
│                                │} else {                                  │
│                                │    echo '×';                            │
│                                │}                                         │
├────────────────┼─────────────────────┤
│$暗号文 = crypt($平文);         │if (crypt($平文, $暗号文) === $暗号文) {  │
│                                │    echo '○';                            │
│                                │} else {                                  │
│                                │    echo '×';                            │
│                                │}                                         │
├────────────────┼─────────────────────┤
│$暗号文 = password_hash(        │if (password_verify($平文, $暗号文)) {    │
│              $平文,            │    echo '○';│                          │
│              PASSWORD_BCRYPT   │} else {                                  │
│          );                    │    echo '×';│                          │
│                                │}                                         │
└────────────────┴─────────────────────┘
  ・「crypt()」照合で比較する左辺と右辺の「$暗号文」は同じ値である必要あり
    「$暗号文」を「crypt($平文)」に置換すると値に相違が発生し照合できない
  ・「password_hash()」には「PASSWORD_DEFAULT」も指定でき
    その時の最善策が選択されるが、現状は「PASSWORD_BCRYPT」が採用

あいまい検索の空文字指定は、すべてにヒットする。
┌──────────────────────────────────────┐
│SELECT *                                                                    │
│    FROM 表                                                                 │
│    WHERE 列 LIKE '%%';                                                     │
└──────────────────────────────────────┘

よって、検索条件に指定がない場合(空文字の場合)、
そのままLIKEにつっこめば、全検索になってくれる。

空文字の場合はWHERE句(の一部)自体を削らなければいけないと勘違いしがちだが
その必要はない(条件分岐でSQL文を作成し分けるみたいなことは不要)