mysql-いくつの列が多すぎますか？

70列を超える可能性があるテーブルを設定しています。テーブルにアクセスするたびに列のデータの一部が必要になるわけではないので、分割することを考えています。次に、これを行うと、結合を使用する必要があります。

どの時点で、列が多すぎると考えられますか？

データベースでサポートされている上限を超えると、多すぎると見なされます。

すべてのクエリですべての列を返す必要がないという事実は、まったく正常です。そのため、SELECTステートメントでは、必要な列に明示的に名前を付けることができます。

原則として、テーブル構造はドメインモデルを反映する必要があります。同じエンティティに属している70（100、何を持っている）属性がある場合でも、それらを複数のテーブルに分割する理由はありません。

テーブルをいくつかの列に分割することにはいくつかの利点があります。これは垂直分割とも呼ばれます。ここにいくつかあります：

1. 多くの行を持つテーブルがある場合、MySQLはテーブル内のすべてのインデックスを再構築する必要があるため、インデックスの変更には非常に長い時間がかかる可能性があります。インデックスを複数のテーブルに分割すると、処理が速くなる場合があります。

2. クエリと列のタイプによっては、MySQLが一時テーブル（より複雑な選択クエリで使用される）をディスクに書き込んでいる可能性があります。ディスクI / Oは大きなボトルネックになる可能性があるため、これは悪いことです。これは、クエリにバイナリデータ（テキストまたはBLOB）がある場合に発生します。

3. テーブルの幅が広いと、クエリのパフォーマンスが低下する可能性があります。

時期尚早に最適化しないでください。ただし、場合によっては、より狭いテーブルから改善を得ることができます。

正規化のルールに違反している場合は多すぎます。データベースを正規化している場合、多くの列を取得するのはかなり困難です。データベースを設計して、問題をモデル化します。特定のdbプラットフォーム用に最適化するための人為的なルールやアイデアは避けてください。

幅の広いテーブルに次のルールを適用すると、1つのテーブルの列がはるかに少なくなる可能性があります。

1. 繰り返し要素や要素グループはありません
2. 連結されたキーに部分的に依存しない
3. 非キー属性に依存しない

ここにあなたを助けるためのリンクがあります。

すべての属性が同じエンティティーに属し、相互に依存していない限り、これは問題ではありません。人生を楽にするために、JSON配列が格納されたテキスト列を1つ持つことができます。明らかに、毎回すべての属性を取得することに問題がない場合。ただし、これはRDBMSに格納する目的を完全に無効にし、すべてのデータベーストランザクションを非常に複雑にします。したがって、データベース全体で従うことは推奨されないアプローチです。

同じテーブルに列が多すぎると、レプリケーションでも大きな問題が発生する可能性があります。マスターで発生する変更はスレーブに複製されることを知っておく必要があります。たとえば、テーブルの1つのフィールドを更新すると、行全体がwになります。