テーブルの列が多すぎると、パフォーマンスが低下しますか？
データの総量の増加は別として、テーブルに多数の列を含めることにはパフォーマンスコストがありますか？もしそうなら、テーブルをいくつかの小さなテーブルに分割することは状況を助けるでしょうか？
これらすべての列が本当に必要な場合（つまり、テーブルの設計が不十分であることを示すだけではありません）、必ずそれらを保持してください。
あなたがいる限り、それはパフォーマンスの問題ではありません
- 行の選択に使用する必要がある列に適切なインデックスを使用する
- sELECT操作で不要な列を取得しないでください
30列、さらには200列の場合でも、データベースに問題はありません。これらすべての列を一度に取得したい場合は、少し難しくなります。
しかし列がたくさんあるのは悪いコードの臭いです。適切に設計されたテーブルにこれほど多くの列が含まれる正当な理由は考えられません。代わりに、他のはるかに単純なテーブルとの1対多の関係が必要になる場合があります。
30列が悪いコードのようなにおいがするというこれらすべての投稿に同意しません。 30以上の正当な属性を持つエンティティを持つシステムで作業したことがない場合は、おそらくあまり経験がありません。
HLGEMによって提供された答えは、実際には最高のものです。私は特に、「自然な分割がありますか....頻繁に使用されるのか、頻繁に使用されないのか」という彼の質問が非常に良い質問であり、自然な方法でテーブルを分割できる可能性があります（手を離れて）。
私のコメントは、あなたのパフォーマンスが現在許容できるものであるならば、あなたがそれを必要としない限り、解決策を再発明することを考えないでください。
あなたがすでに答えを選択しているとしても、私はこれについて検討するつもりです。はい、テーブルが広すぎると、パフォーマンスの問題（およびデータの問題も）が発生する可能性があるため、1対1の関係を持つテーブルに分割する必要があります。これは、データベースがデータを格納する方法によるものです（少なくとも、SQL ServerではmySQlについてはよくわかりませんが、データベースがデータを格納およびアクセスする方法については、ドキュメントを読む価値があります）。
30列は幅が広すぎる場合とそうでない場合がありますが、列の幅によって異なります。 30列が占める合計バイト数を合計すると、レコードに格納できる最大バイト数よりも広いですか？
必要な列のいくつかは他の列よりも少なくなります（言い換えると、必要な情報と頻繁に使用される情報と、他の場所ではなく1つの場所にしか表示されないその他の情報との間に自然な分割があります）。次に、テーブルを分割することを検討してください。
一部の列がphone1、phone2、phone3のようなものである場合、列の数は関係ありません。代わりに、1対多の関係を持つ関連テーブルが必要です。
一般に、30列は異常に大きくはなく、おそらく問題ありません。
技術的に言えば、30列は絶対に問題ありません。ただし、多くの列を持つテーブルは、データベースが適切に正規化されていないことを示していることがよくあります。つまり、冗長なデータや一貫性のないデータが含まれている可能性があります。
いたるところにselect * from yourHugeTableがない限り、問題ないはずです。常に必要な列のみを選択してください。
30は私にはあまり多くないようです。必要なインデックスと適切なSELECTクエリに加えて、幅の広いテーブルには、次の2つの基本的なヒントが適しています。
- 列を定義する できるだけ小さい 可能。
- テーブルごとに多数の列がある場合は、VARCHARやTEXTなどの 動的列 の使用をできるだけ避けてください。 CHARなどの固定長の列を使用してみてください。これは、ディスクストレージとパフォーマンスのトレードオフです。
たとえば、100列以上の列を持つ「person」テーブルの「name」、「gender」、「age」、「bio」の列の場合、パフォーマンスを最大化するには、次のように定義するのが最適です。
- 名前- CHAR（70）
- 性別-TINYINT（1）
- 年齢-TINYINT（2）
- バイオ-テキスト
アイデアは、列を可能な限りsmallとして、fixedの長さで定義することです。合理的に可能な場合。動的列はテーブル構造の最後に配置する必要があるため、固定長の列はその前にすべてあります。
言うまでもなく、これにより大量の行で無駄になる膨大なディスクストレージが発生しますが、パフォーマンスが必要な場合は、それがコストになると思います。
もう1つのヒントは、進むにつれて、他の列よりもはるかに頻繁に使用（選択または更新）される列を見つけることですそれらを別のテーブルに分離して、使用頻度の低い列を含む他のテーブルと1対1の関係を形成し、より少ない列でクエリを実行します。
通常、30列は過剰な数とは見なされません。
一方、3つの千列... 非常に広い「テーブル」をどのように実装しますか？
パフォーマンスを超えて、データベースの正規化は、テーブルとリレーションが多すぎるデータベースの必要性です。正規化により、モデルと柔軟な関係に簡単にアクセスして、さまざまなSQLクエリを実行できます。
ここに示されているように 、正規化には8つの形式があります。ただし、多くのシステムでは、第1、第2、および第3の正規形を適用するだけで十分です。
したがって、関連する列を選択して長いSQLクエリを作成する代わりに、適切に正規化されたデータベーステーブルの方が適しています。
使用法に関しては、一部の状況で適切です。たとえば、テーブルが一部の列を共有し、他の列は共有しない複数のアプリケーションを提供する場合や、レポートにすべてのデータ遷移なしでリアルタイムの単一データプールが必要な場合などです。 200列のテーブルがその分析力と柔軟性を可能にするなら、私は「長くなる」と言うでしょう。もちろん、ほとんどの場合、正規化は効率を提供し、ベストプラクティスですが、必要に応じて機能することを実行してください。