列が多すぎるとは何列ですか?[閉まっている]

https://stackoverflow.com/questions/3184478

02-10-2019
|

質問

ここで多くの人が 1 つのテーブルに 20 以上 (私は 55 個も見たことがあります) 列があるテーブルを引用していることに気づきました。現在、私はデータベース設計の専門家であるつもりはありませんが、これはひどい行為であると常に聞いてきました。これを見たとき、私は通常、1 対 1 の関係を持つ 2 つのテーブルに分割することを提案します。1 つは最も頻繁に使用されるデータを含み、もう 1 つは最も頻繁に使用されないデータを含みます。ただし同時に、パフォーマンスの問題 (JOIN の減少など) が発生する可能性があります。そこで私の質問は次のとおりです。

本当に大規模なデータベースの場合、通常は多くの NULL 値が発生するにもかかわらず、大量の列を持つことには実際に利点があるのでしょうか?

どちらがパフォーマンスに影響を与えますか?多数の NULL を含む多数の列、それとも多数の JOIN を含む少数の列ですか?

解決

テーブルの設計は、保存するために必要なエンティティによって異なります。すべてのデータが一緒に属している場合、50列（または100）が正しいことかもしれません。

テーブルがそうである限り正規化, 、データベースの機能と最適化の必要性を除いて、サイズに関する経験則はありません。

他のヒント

私はOdedに同意します。私は500列のあるテーブルを見て、それらのすべての列が正しい場所にありました。日常のオブジェクトについて保存したい事実の数を考慮してください。そうすれば、すぐにその理由がわかります。

これらのすべての列を選択するのが不便であることが証明されている場合、またはそれらのごく一部に関心がある場合に選択する列を指定することが、ビューを定義する価値があると思うかもしれません。

列が多すぎる列はいくつありますか？

それがもはや意味がない、または別の列を追加するのが正しいと感じたとき。

通常、アプリケーションに依存します。

odbc には 8000 文字の制限があります。つまり、これは物理的な限界であり、それを超えると非常にイライラすることになります。

私は 138 列あるテーブルで作業しました。それはひどく書かれており、正常化された可能性があります。このデータベースは、なぜデータベース設計に規則があるのか疑問に思い、それらをすべて一度にテストすることにした人が作成したもののようですが。

データウェアハウスおよびレポートサーバーを使用する場合、非常に幅の広いフラット化されたテーブルが存在するのは非常に一般的です。それらは単にはるかに高速であり、パフォーマンスのためにデータベースを完全に RAM に保存する必要がないことを意味します。

私の経験によると、特に大きなデータベースではあまりにも頻繁に起こる傾向があるため、結合が少ない方が良いでしょう。データベーステーブルが単一のエンティティ（学生、教師など）を保存するように設計されている限り、これは問題ありません。これは、後でコードのオブジェクトとして表されるようにします。したがって、エンティティをいくつかのテーブルに分割する場合、後でオブジェクトを入力するためにいくつかの結合を使用する必要があります。また、ORMを使用してデータアクセスレイヤー（.NETのLINQなど）を生成すると、各テーブルの個別のクラスが生成されます（もちろん、それらの間に関係がありますが、それでも）これは使用が困難です。

もう1つのことは、クエリでどの列を返すかを指定でき、これによりアプリケーションに渡されるデータが削減されますが、別のテーブルから1つの列も必要な場合は、結合を行う必要があります。そして、ほとんどの場合、非常に多くの列があるため、DBに大量のデータを保存する確率が高くなります。したがって、この結合は、ヌルよりも多くの害を及ぼすでしょう。

私が取り組んだすべてのプロジェクトは異なるため、各ストーリーのバランスを見つける必要があります。

列が多すぎると、多くのヌル（悪）とテーブルがマッピングされている扱いにくいオブジェクトが生じます。これは、IDEの読みやすさを損ない、メンテナンスを妨げます（開発コストの増加）。場合によっては高速読み取りが必要な場合、場合によっては、レポートまたはクエリのみに使用される非定型テーブルを使用します（「CQRS」パターンの検索）。はい「人」には100万の属性がありますが、これらの単位テーブル（設計前処理の正規化）を分解して、新しいユースケースごとに新しい列を追加する代わりに、より小さなエンティティ（「アドレス」、「電話」、「趣味」）に一致させることができます。小さいサイズのオブジェクト（およびテーブル）を持つことは、非常に多くの利点をもたらします。それらは、ユニットテスト、OOP、堅実な実践などを可能にします。

また、結合を避けるために多数の列を積み上げることに関しては、読み取りと書き込みの両方の典型的なワークロードを想定して、インデックスメンテナンスによって結合を回避することでパフォーマンスの向上が失われると思います。読み取りパフォーマンスのためにフィールドにインデックスを追加することは、これらのフィールドを自分のテーブルに移動する必要性を示す可能性があります。

パフォーマンスのヒットはどれですか：たくさんのヌルを備えたたくさんの列、または多くの結合がある列が少ないですか？

それは純粋にあなたが保存するデータ、あなたが作成するインデックスなどに依存します。何を保管しているのかわからずに、ある人が他の人よりもうまく機能することを誰も保証することはできません。一般に、正規化ルールは、大きなテーブルがある場合、さまざまなテーブルとユーザーFKEYにデータを「強制」します。 6-7レベルのクエリで6〜7レベルで結合することで終了できます。これにより、エラーを引き起こすことがあります。これは、単純なクエリでより大きなクエリでエラーを作成する可能性がはるかに大きいためです。

あなたがしていることのいくつかの要件を投稿するなら、多分私たちはあなたがDBを適切に設計するのを助けることができるかもしれません。

また、テーブルのUSECASEに大きく依存します。読書のために最適化したい場合は、1つのテーブルにすべてをまとめることをお勧めします。

NO-SQLの世界（たとえばCassandra/HBase）では、列の数に制約がなく、実際には多くの列を持つことは良い習慣と考えられています。これは、保存方法からも発生します（ギャップなし）。調査中に価値があります。

TSQLテーブルは言うまでもなく、データセットに60以上の列が必要なビジネスニーズは何ですか？そのようなビジネスニーズがある場合、ピボットが順調で、列は行である必要があります。たとえば、鉱業では、アッセイで600の異なる測定値が採取される場合があります。各測定の名前は列名です。しかし、なぜ600列と測定の行を持つテーブルを作成するのですか？地質学者は、おそらく毎日鉱山を測定し、1列の600列のログを記入します。地質学者が彼の心を失い、彼は十分に長く紙を見つけることができないように私には聞こえます。おそらくロールが機能するでしょうが、彼はロールを丸めて再びロールアップする必要があります。

列が同じエンティティであるか異なるエンティティのかどうかによって、クエリをクエリする際に結合を使用することを避けることができる場合、単一のテーブルを使用することをお勧めします。

たとえば、一部のフィールドがジュニアワーカーによって編集されるワークフローのデータベースデザインを行っていると仮定し、一部のフィールドは上級労働者によって編集されます。この場合、すべての列を単一のテーブルに載せることをお勧めします。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow