前回に続いて、セット・アット・ア・タイム 法の実装形 （プロダクト としての RDB） の 「からくり」 を解析にする。

　
　セット・アット・ア・タイム 法では、複合選択条件は 「同一 row の検証」 をするために トラヴァーサル・テーブル を生成することを、前回、述べた。複合選択条件のことを専門用語では 「CBS （Compound Boolean Selection）」 という。

　
1. order-by と トラヴァーサル・テーブル

　単一選択条件 （連言や選言を使わない 1つの条件文） はどうかと言えば、単一選択条件であっても、トラヴァーサル・テーブル を生成することがある。以下の例を使って説明する。

　
　従業員の データ は従業員番号順に並べられている。
　さて、これらの データ を名称順に並べて一覧表示する （「従業員名称→従業員番号→住所」 の順に並べる）。

　物理的な配列 （native-sequence） は従業員番号順に並んでいるので、並び直さなければならない。
　そのときに使う SQL 句が 「order-by」 である （「group-by」もこれに準ずる）。

　並び直すためには作業域 （work-area） を用意しなければならない。
　すなわち、sort-work 域と sort-out 域を用意しなければならない。
　そのために、RDB は （作業域として） トラヴァーサル・テーブル を生成する。

　つまり、「order-by」 を使えば、トラヴァーサル・テーブル が生成される。
　となれば、資源を費消して パフォーマンス は低下する。

　したがって、「order-by」 を使わないで並び直すことを考えなければならない。

　
2. まとめ

　以上に述べてきた点をまとめれば、以下のようになる。

　（1） セット・アット・ア・タイム 法は 「MAX-Start I/O」 を制限できない。
　　　つまり、セット・アット・ア・タイム 法は テーブル の全体を走査する。

　（2） 「order-by」 を使えば、（sort 域を用意するために） トラヴァーサル・テーブル を生成する。

　（3） 複合選択条件を使えば、（「同一 row 上の検証」 をするために） トラヴァーサル・テーブル を生成する。

　
　基幹系の多量 データ・多量 トランザクション を対象として、RDB の高 パフォーマンス を実現するためには、以上の諸点を回避しなければならない。
　RDB は、バージョンアップ の過程のなかで、（セット・アット・ア・タイム 法の上述した弱点を回避するために） レコード・アット・ア・タイム 法 （indexing を使って row 単位に データ を アクセス する やりかた） を導入してきた。しかし、導入された レコード・アット・ア・タイム 法は 「B ツリー 構造 （Balance-Tree 構造）」 を基礎とした I-SAM （あるいは、VSAM） 式であった。「B ツリー 構造」 を使った レコード・アット・ア・タイム 法は、基幹系の多量 データ・多量 トランザクション を対象としたら、かならずしも、高 パフォーマンス を実現することができない。

　次回は、レコード・アット・ア・タイム 法を説明する。