「ヌルとバッグを廃止せよ」—Relの設計者がSQLの根本欠陥に挑む

良い点もあるが、私がRDBMSを構築するチームにいた時に気づいた大きな問題が2つあると思う。

* またしてもnullの最善の解決策である代数的データ型を無視している。これがあれば多くの問題は自動的に解決する。

* バッグに対する反論：

論文の最良のアイデアは、RDBMSが実際には内部的に異なるデータ構造と時間表現を使用しており、それはユーザーには関係ないという点だ。正しい。

そして、バッグをユーザーに提示すべきではないという結論に飛躍するが、表示する必要があることは認めている。

これは間違いであり、常に見落とされている主な理由は、2つの同一の値が存在することは間違いだと仮定していることだ。

「ジョン、ジョン」という2人の別々の人物がいるかもしれないが、現時点では区別する情報がなく、IDを追加しても役に立たない。それでも、このデータはそのまま正しい。

言語はこれに対処できるようにしなければならない。配列言語、手続き型、関数型、命令型、宣言型などができるのに、リレーショナルだけができないと主張するのは馬鹿げている。

言語が純粋性のために意図的に制限されていると言うのは、確かに一部のケースでは理想的だが、その純粋性はエンジンやコンパイラが追跡すべきものであり、私のデータを歪めるべきではない。

そして、バッグを持つことのパフォーマンスが無視されるところは簡単に反論できる：DBMSを実装してプロファイリングしてみればいい。

追伸：セットが多くの利点をもたらすのは事実で、場合によっては理想的だ。しかし、現実世界に直面するとすぐに、両方が必要だとわかる。Bツリーだけでは不十分で、ハッシュベースのインデックスが必要になるのと同じだ。