リレーションは、大きくて非効率的なテーブルよりも遅いですか？

私の仕事では、「コンピューターの処理能力のために」最初の正規形（列全体でグループを繰り返す、空/ null値を使用）に何度も違反するように依頼されました。簡単に言えば、「学生」テーブルには、私の提案ではなく、少なくとも8つの空のフィールド（たとえば、telephones：telephone1、telephone2、telephone3 ...）が必要です。電話番号（およびその他のメタデータ）を保持する「telephone」テーブル外部キーは学生ID番号です。私の上司は、リレーションを使用する代わりに、「CPUサイクルが少なく、それがWebプラットフォームで問題になる」ため、それらをそのように保存する方が良いと述べています。最悪の場合、それはごくわずかです。

その例では、リレーションの使用（テーブルが中規模のWebアプリケーションの多くのレコードで満たされていると想定）は、そのようなテーブルスキーマを使用するよりも著しく遅いですか？

裏付けとなるいくつかの実際の事実がなければ、誰もどのようにそのような発言をすることができるのかわかりません。クエリがCPUバウンドの場合は、そのボトルネックを軽減する方法を探す必要があります。

非正規化されたデータベースのパフォーマンスが最も良いと上司が感じているように聞こえますが、それが正しいかどうかを判断するためにアプリケーションについて十分に知りません。このテーブルの予想される削除、更新、挿入の数はいくつですか？

このような非正規化された設計により、CPU時間を削減できると思いますが、ディスクI / Oが増えると思います。また、ディスクからの物理的な読み取りは、CPUサイクルよりもはるかにコストがかかるため、上司は非常に具体的な測定基準（CPU）を持っており、その結果、非常に具体的な設計が必要ですか？もしそうなら、私は単に要求されたものを構築し、実行されているクエリのCPUコストに関するメトリックを保持します。時間の増加が見られる場合は、設計の変更を提案することをお勧めします。

実際、上司が見たいすべてのメトリックのリストを取得し、それらを時間の経過とともに追跡することは、おそらく良い考えです。