前回述べたが （228 ページ 参照）、「INDEX-only」 を使う際には、更新 （追加、削除、変更） を前提にして、1つの テーブル に対して生成する 「CREATE INDEX」 の数を制限している。
　というのは、更新 （追加、削除、変更） を前提にすれば、「CREATE INDEX」 の多用は パフォーマンス を逆に低下することになるから。

　更新 （追加、削除、変更） を前提にして、「驚異的な」 パフォーマンス を実現するための 「CREATE INDEX」 の限界数が前回述べた制限数である。その制限数の枠内であれば、テーブル に対して更新が多くても、（「INDEX-only」 を使った） 「驚異的な」 パフォーマンス を実現することができる。

　
　N は 「CREATE INDEX」 の数である。

　上述の I/O 回数の内訳に関する詳細な説明は割愛するが、たとえば、5つの 「CREATE INDEX」 が定義されている データ を ADD すれば 6 回の論理 I/O が起こるし、DELETE すれば、7 回の論理 I/O が起こるということを理解すればよい。ここで注目したい点は、更新 （UPDATE） では、ADD の論理 I/O 回数が一番に少ない、という点である。

　つまり、論理 I/O を削減するには、（CHANGE と DELETE を使わないで） ADD を使えばよい、ということである。
　したがって、RDB を使って正規形を実装したなら、以下の 2つの やりかた を使えばよい。
　　（1） 「INDEX-only」
　　（2） 「ADD-only」

　ちなみに、プログラム が出した更新の論理 I/O 回数を、RDB のなかでは、少ない物理 I/O 回数 （EXCP） にするために 「パイプライン 機能 （pipeline）」 が搭載されていることがある。たとえば、100 回の論理 I/O 回数をまとめて 1 回の物理 I/O 回数にする機能である。ただし、パイプライン 機能は READ に対しては適用されない。