ここの多くの人々が、1つのテーブルに20以上（私は55も見たことがあります）の列を持つテーブルを引用していることに気づきました。今ではデータベース設計の専門家のふりをしていませんが、これは恐ろしい習慣だといつも聞いています。これを見ると、通常、1対1の関係で2つのテーブルに分割することをお勧めします。1つは最も頻繁に使用されるデータを含み、もう1つは最も頻繁に使用されないデータを含みます。同時に、パフォーマンスの問題が発生する可能性があります（JOINの減少など）。だから私の質問はこれです：
本当に大規模なデータベースに関して言えば、これは通常多くのNULL値につながるという事実にもかかわらず、実際には大量の列を持つことに利点がありますか？
パフォーマンスに影響を与えるのはどちらですか。NULLが多い列が多いのか、JOINが多い列が少ないのでしょうか。
テーブルのデザインは、格納する必要のあるエンティティによって異なります。すべてのデータが一緒に属している場合は、50列（または100列）が正しい方法である可能性があります。
テーブルが正規化されている限り、データベース機能と最適化の必要性を除けば、サイズに関する経験則はありません。
Odedに同意します。500列のテーブルを見たことがありますが、すべての列が正しい場所にありました。日常のオブジェクトについて保存したい事実の数を考えてみてください。そうすれば、すぐにその理由がわかります。
これらの列をすべて選択するのが不便な場合、または列のごく一部にのみ関心がある場合に選択する列を指定するのが不便な場合は、ビューを定義する価値があると思うかもしれません。
列が多すぎますか？
意味がなくなった、または別の列を追加するのが正しいと感じた場合。
通常、アプリケーションによって異なります。
列が多すぎると、多くのnull（悪）が発生し、テーブルがマップされる扱いにくいオブジェクトになります。これにより、IDEの可読性が損なわれ、メンテナンスが妨げられます（開発コストが増加します）。高速読み取りが必要な場合は、非正規化テーブルを使用します。たとえば、レポートまたはクエリにのみ使用されます（「CQRS」パターンを検索します）。はい、「Person」には100万の属性がありますが、新しいユースケースごとに新しい列を追加する代わりに、これらのモノシックテーブル（設計は正規化に先行）を分割して、より小さなエンティティ（「住所」、「電話」、「趣味」）に一致させることができます。小さいサイズのオブジェクト（およびテーブル）があると、非常に多くの利点があります。ユニットテスト、OOP、SOLIDプラクティスなどを可能にします。
また、結合を回避するために多数の列をバンチングすることに関しては、読み取りと書き込みの両方の一般的なワークロードを想定すると、インデックスの保守によって結合を回避することによるパフォーマンスの向上は失われると思います。読み取りパフォーマンスのためにフィールドにインデックスを追加することは、それらのフィールドを独自のテーブルに移動する必要があることを示している可能性があります。
odbcの文字数制限は8000です。これを超えると、非常にイライラする物理的な制限になります。
私は138列のテーブルで作業しました..それはひどく書かれていて、正規化できたはずです。このデータベースは、なぜデータベース設計に慣習があるのか疑問に思い、それらすべてを一度にテストすることを決定した誰かの作成であるように見えます。
データウェアハウジングおよびレポートサーバーを使用する場合、非常に幅の広いフラット化されたテーブルを使用することはかなり一般的です。これらははるかに高速であり、パフォーマンスのためにデータベースエントリをRAMに保存する必要がないことを意味します。
私の経験によると、特に大規模なデータベースでは結合が頻繁に発生する傾向があるため、結合を少なくする方が適切です。データベーステーブルが単一のエンティティ（学生、教師など）を格納するように設計されている限り、これは問題ありません。これは、後でコード内でオブジェクトとして表されるようにするためです。したがって、エンティティを複数のテーブルに分割する場合は、後でオブジェクトを埋めるために、いくつかの結合を使用する必要があります。また、ORMを使用してデータアクセスレイヤー（.NetのLinqなど）を生成すると、テーブルごとに個別のクラスが生成され（もちろん、それらの間には関係がありますが）、これは使いにくくなります。
もう1つは、クエリで返す列を指定できることです。これにより、アプリケーションに渡されるデータが削減されますが、別のテーブルの1つの列でも必要な場合は、結合を行う必要があります。また、ほとんどの場合、列が非常に多いため、データベースに大量のデータが格納される可能性が高くなります。したがって、この結合はNULLよりも害を及ぼします。
私が取り組んだプロジェクトはそれぞれ異なるので、それぞれのストーリーのバランスを見つける必要があります。
また、テーブルのユースケースにも大きく依存します。読み取り用に最適化する場合は、すべてを1つのテーブルにまとめておくことをお勧めします。
NO-SQLの世界（たとえば、cassandra / hbase）では、列の数に制約はなく、実際には多くの列を持つことをお勧めします。これは、保存方法（ギャップなし）からも発生します。調査する価値があります。
パフォーマンスに影響を与えるのはどちらですか。NULLが多い列が多いのか、JOINが多い列が少ないのでしょうか。
これは、保存するデータ、作成するインデックスなどに完全に依存します。何を保存しているかを知らなければ、ある人が別の人よりもうまく機能することを保証することはできません。一般に、正規化ルールは、大きなテーブルがある場合にデータを異なるテーブルとユーザーFKeyに「強制」しますが、常に1つの大きなテーブルよりもパフォーマンスが優れていることに同意しません。単純なクエリよりも大きなクエリでエラーが発生する可能性がはるかに高いため、エラーが発生することがある数十のクエリで6〜7レベルの結合で終了できます。
あなたがしていることのいくつかの要件を投稿する場合、多分私たちはあなたがDBを適切に設計するのを手伝うことができます。
列が同じエンティティであるか異なるエンティティであるかに応じて、クエリ中に結合を使用しないようにすることができる単一のテーブルを使用することをお勧めします。
たとえば、一部のフィールドがジュニアワーカーによって編集され、一部のフィールドがシニアワーカーによって編集される、ワークフローのデータベース設計を行っているとします。この場合、すべての列を1つのテーブルに含めることをお勧めします。