一テーブルのカラム数について【ＤＢの正規化と非正規化】

引用：http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=26266&forum=26&start=8&12

■　問題提起
「DBを正規化すると遅くなる」は誤解だそうです。

実体験から感覚的になんとなくそんな気がしていましたが、
実証結果を発表したプロジェクトがあります。

http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/
興味を惹かれたので、詳細を見てみました。
http://www.doaplus.com/html/bun03_20051101.html

◎　反論１

結論ありきの無理やりな実証、というのが素直な感想です。

「非正規化は早いか否か」という問題設定ではなく、早くなるケースもあるということを前提に、どういうケースなら効果を得られるのか・得られないのかというアプローチのほうが良いと思うんですが。

正規化モデルでは性能要件を満たせなくて、非正規化モデルなら満たせる場合だけ非正規化すればよいのです。実際に非正規化する場合は、もちろんプロトタイプとかを用いた実機検証が必要。

そして「非正規化のほうが早い」というだけで非正規化しないことが重要。性能に関する比較を行う場合は、「方式1と方式2を比較」だけではなく、「性能要件と比較」という観点を忘れるべきではありません。

◎　反論2

私は当該ページを、正規化を推奨するためのプロパガンダと感じました。正規化だけでなく、適切な冗長化がよりよいパフォーマンスを生むと考えている私は、あのページの内容にはまったく同意できません。

世の中の冗長化が「適切な冗長化」だったらいいんですけど。。

概念分析 → 正規化 → ボトルネックを冗長化 （オブジェクト参照の競合排除）

って手順ならいいわけです

もしくは、DB設計に精通した方が分析からいきなりボトルネック箇所を
冗長化した設計にできるのなら正規化と一緒でもいいかもしれません。

現実は違って、概念分析も行わず画面をそのままテーブルにしたような
元から冗長化されまくった構造を見かけることが非常に多いです。

正規化されてないように見えても、実は正規化されている場合もあります。
例えば、商品マスタと販売系のトランザクションテーブルで重複して商品
データを持っているような場合だと、商品マスタは今後扱っていく商品、
販売側は販売時点のデータ、というような別の意味になったりもします。

冗長化を行う前提として、適切な論理設計が必要なのではないですか？
パフォーマンス目的の冗長化はあくまで物理レベルのチューニングであって、
その元となる正規化された構造が必ずあるはずですから。

とはいえ、列方向への非正規化は問題外じゃないかと。