- - PR -
一テーブルのカラム数について
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2005-11-24 12:28
興味を惹かれたので、詳細を見てみました。 http://www.doaplus.com/html/bun03_20051101.html 結論ありきの無理やりな実証、というのが素直な感想です。 「非正規化は早いか否か」という問題設定ではなく、早くなるケースもあるということを前提に、どういうケースなら効果を得られるのか・得られないのかというアプローチのほうが良いと思うんですが。 正規化モデルでは性能要件を満たせなくて、非正規化モデルなら満たせる場合だけ非正規化すればよいのです。実際に非正規化する場合は、もちろんプロトタイプとかを用いた実機検証が必要。 そして「非正規化のほうが早い」というだけで非正規化しないことが重要。性能に関する比較を行う場合は、「方式1と方式2を比較」だけではなく、「性能要件と比較」という観点を忘れるべきではありません。 | ||||
|
投稿日時: 2005-11-24 13:52
世の中の冗長化が「適切な冗長化」だったらいいんですけど。。 概念分析 → 正規化 → ボトルネックを冗長化 って手順ならいいわけです。 もしくは、DB設計に精通した方が分析からいきなりボトルネック箇所を 冗長化した設計にできるのなら正規化と一緒でもいいかもしれません。 現実は違って、概念分析も行わず画面をそのままテーブルにしたような 元から冗長化されまくった構造を見かけることが非常に多いです。 正規化されてないように見えても、実は正規化されている場合もあります。 例えば、商品マスタと販売系のトランザクションテーブルで重複して商品 データを持っているような場合だと、商品マスタは今後扱っていく商品、 販売側は販売時点のデータ、というような別の意味になったりもします。 冗長化を行う前提として、適切な論理設計が必要なのではないですか? パフォーマンス目的の冗長化はあくまで物理レベルのチューニングであって、 その元となる正規化された構造が必ずあるはずですから。 とはいえ、列方向への非正規化は問題外じゃないかと。 | ||||
|
投稿日時: 2005-11-24 15:26
「冗長」と見なすには情報が少ないのではないでしょうか?
通常のようにエンティティだけを見ていれば、商品名(名称)、単価(金額) という項目が複数あるということだけで「冗長」と見なせないでもないです が、本当に同じ扱いでよいのですか? 例えば、スレ主さんが横方向に持とうと思われたこの組み合わせが、 商品名は各国語で表記されているもの。 Key項目の場合のレート換算していない各国通貨による単価表記。 という場合なら、同じように見えて違うものです。これを1テーブルで 商品名、単価というレコード方向に持つのも?な感じがします。 (別テーブルにするということは物理設計での話で別物) それとは違って、部品展開など構成品のテーブルなどを考えると、フィー ルド方向に持つのは、共用部品とか拡張性の面では非常にまずい設計に なってしまいます。 というように、そのフィールド内容がどういう性質のものかがわからないと、 どういう設計(論理設計)をするのがベターかというのは判断できないと思 うのですがね。 | ||||
|
投稿日時: 2005-11-24 15:43
15国(15言語, 15通貨)しか対応できないことになりますよ? やはり、国コードをつけて正規化するべきだと思います。・・・いいたいことは分かりますけどね。 私は、顧客情報の電話番号を非正規化したことがあります。顧客ごとに電話番号をひとつではなく最大2つ登録できるんですが、3つ以上電話番号を持っている人も主要な連絡先を 2つ入れれば十分だよね、ってことでレコードに電話番号1、電話番号2 と並べて持たせるという設計にしました。 | ||||
|
投稿日時: 2005-11-25 16:17
みなさん、ご返信が遅くなってしまい大変申し訳ございませんでした。
僕は、設計よりはプログラムのコーディングが多いのですが、現場でもやはり横にずらっと並んだテーブルを多く見てきました。 結構ひどかったのは col1 col2 col45 という、何の項目かまったくわからないものまでありました。 // さすがに、設計者出て来いという感じでした・・・。 そういうこともあって、ずらっと並べるテーブルに少し戸惑いを感じるのかもしれません。 今回、皆様のご意見をお伺いし、もう一度正規化について調べてみようと思います。 ありがとうございました。 | ||||
