SQL Serverの列のデザイン

Question

私はいつも私のSQLデータベースをできるだけシンプルで理解しやすいものにしようとしました。 今まで私はいつも限られた数の列を使っていました。私は20を超えることはなかったと思います。今、もっとたくさんの列があれば、私の人生を楽にしてくれるものが1つあります。 200列としましょう。 （行ではない）。あなたはそれについてどう思いますか？

私が知りたいのは、それが悪い考えであるならば、私はこれをやっているのではなく、もし他の可能性があるならば、誰かが既にそのようなことを経験していて、テーブル。

Answer 1

私は白黒ではないと思います。列数が多いと、行のサイズが大きくなり、パフォーマンスが低下します（I/Oの増加）がありますが、パフォーマンスの低下が1箇所で発生する場合は、他の箇所のパフォーマンスが向上するために相殺されます。

このテーブルの予想行数、クエリの頻度、実際にアクセスする列の数、代替デザインとの比較方法は次のとおりです効率と複雑さの条件。

Answer 2

ルーク

実際には、使用しているシステムのタイプによって異なります。トランザクションシステムの例では、大部分の表には最大50の列しかないので、冗長なデータ属性はほとんどありません（プロセスの日付がある場合は、プロセス月またはプロセスの年が別の列として必要ありません）。これはもちろん、レコードが頻繁に更新/挿入され、1つの行を更新するたびにすべての冗長属性を更新する必要があるためです。

データウェアハウス/レポート環境では、（エンティティの属性を持つ）次元テーブルの場合、特定のエンティティを分類するさまざまな方法がありうるため、100以上の列を持つのが一般的です。オフピーク時に一度データがロードされてから、大半の選択でデータが使用されるため、あまり問題になりません。

それが依存...あなたは完全にリレーショナルシステムをしたい場合は、200であってもよい。..

http://en.wikipedia.org/wiki/Database_normalization

http://en.wikipedia.org/wiki/Star_schema

だから、答えは詳細を知るために、これらのリンクを見てみましょう+列はあなたのデータを正規化する必要があることを示す赤い旗です（そうでないかもしれません）。更新とインデックスは、このようなシステムで懸念すべき2つのものです。

Answer 3

多くの列および/または幅の広い列よりも、列幅が小さくなると、幅が小さくなります。

なぜですか？行サイズが狭いほど、8Kページに収まる行数が増えます。つまり、I/Oを少なくして、ページをバッファするために必要なメモリを少なくします。それは常に良いことです。

ドメインがオブジェクト上に多くの属性を必要とする（うまくいけば）まれなケースでは（1-1のオブジェクトテーブルマッピングの前提で）、1-1の関係の2つのテーブルに分割することを検討する必要があります。頻繁に使用される列。