Fields約35列のデータベーステーブル（と呼ばれる）があります。それらのうちの11は、約300.000行ごとに常に同じ定数値を含み、メタデータとして機能します。
この構造の欠点は、これらの11列の値を更新する必要がある場合、300.000行すべてを更新する必要があることです。
すべての共通データを別のテーブルに移動し、300.000の場所ではなく、1つの場所で1回だけ更新することができました。
ただし、このようにすると、フィールドを表示するときにINNER JOIN's、2つのテーブルの間に作成する必要があります。これにより、SELECTステートメントが遅くなることがわかっています。
列の更新は、データの読み取り（表示）よりもまれにしか発生しないと言わなければなりません。
最高のパフォーマンスを得るには、データをデータベースに保存する必要があることをどのように提案しますか？
すべての共通データを別のテーブルに移動し、300.000の場所ではなく、1つの場所で1回だけ更新することができました。
つまり、正常なデータベース設計と標準の正規化です。
これは「多くの空のフィールド」に関するものではなく、残酷なことに大量の冗長データに関するものです。分離すべき定数。別のテーブル。これにより、処理が高速化される場合もあります。データベースが非常に小さいため、データベースがメモリをより効率的に使用できるようになります。
重要なものを隠していない限り、別のテーブルを使用することをお勧めします（もちろん、試して測定する方が良いでしょうが、すでに知っていると思います）。
実際には、より高速な選択を取得することもできます。小さなテーブルに参加すると、同じデータを300000回フェッチするよりも安価になります。
これは、非正規化された設計の典型的な例です。場合によっては、（SELECT）パフォーマンスのために非正規化が行われ、常に意図的で測定可能な方法で行われます。それによってパフォーマンスが得られるかどうかを実際に測定しましたか？
データがキャッシュに収まる場合、および/またはJOINが異常に高価である場合1、JOINを回避することでパフォーマンス上の利点が得られる可能性があります。ただし、非正規化されたデータはより大きく、キャッシュの限界をより早くプッシュし、I / Oを増やし、JOINを回避することで得た利益を逆転させる可能性があります。実際にはパフォーマンスが低下する可能性があります。
そしてもちろん、間違ったデータを取得することは、どれほど迅速に実行できたとしても、役に立ちません。非正規化により、データベースのデータの不整合に対する回復力が低下します2。このリスクを正当化するには、パフォーマンスの違いをかなり劇的にする必要があります。
1ここではそうではないようです。
2たとえば、一方のアプリケーションが既存の行を変更し、もう一方のアプリケーションが新しい行を挿入するが古い値を使用する並行環境で何が起こるかを検討しましたか（最初のアプリケーションはまだコミットされていないため、2番目のアプリケーションが変更があったことを知っていますか）？
最良の方法は、データを分離し、それらの11列で2番目のテーブルを形成し、それをマスターデータテーブルと呼ぶことです。これは主キーを持ちます。
この主キーは、最初のテーブルの30,000行で外部キーとして参照できます。