<< 経済リソースと経済エージェント | main | Spring iBatis で O/R マッピング >>

テーブル設計 "いやな臭い"

Scott Ambler の Refactoring Databases から

次のような現象を発見したら、データベースのリファクタリングを考える。
テーブル設計の再検討が必要。

・多目的に使われるカラム
・多目的に使われるテーブル
・重複したデータが別がテーブルに保存されている(不一致)
・カラムが多すぎるテーブル
・レコードが多すぎるテーブル
・特定の桁に意味を持たせたコード(上位3桁が商品大分類...)
・怖くて、データベースの設計は変更できない (末期症状?)

一つの入れもの(カラムやテーブル)、なんでもかんでもつっこんでしまう
「詰め込み症候群」ですね。

洗練された設計は、カラムやテーブルがとてもシンプルな目的だけの
ために存在している。

データーベース自体は、情報を集約して管理する仕組みですが、
それと、カラムやテーブルになんでも詰め込むのは別の問題です。

顧客関連の情報を、とにかく CUSTOMER テーブルにカラムを追加して
なんでもかんでも、詰め込むと、何が起きるか?

・SQL 文が複雑になる
・プログラムが複雑になる
・見通しが悪くなる(障害・データ不整合の調査に時間がかかる)
・変更ができない (変更すると何が起きるか、誰も見通せない)

良いことは何もありません。

大原則
「関心の分離」(ひとつの関心に集中)

クラス設計でも、テーブル設計でも、役割が単純で明快なクラス/テーブルを
設計すること。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
 123456
78910111213
14151617181920
21222324252627
28293031   
<< May 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM