主キーを設計するということ

CSS85_mbakubiwokashige20131019500

主キーをその場その場でちゃちゃっと設計していませんか?

こんにちは。です。

渡辺幸三さんは、セミナーに参加させていただいたり書籍を購入してサインまで(!)いただいた事もあるほど、学ばせていただいています。

その渡辺さんが先日、ブログに投稿されました。

{a,b,c,d}の複合主キーをもつテーブルXがある。ところが、別のテーブルYからテーブルXの特定レコードにアクセスする処理を見ると、{a,d}の参照キーでロジックが書かれている。bとcが抜けているのでバグではないかと問うと、「aとdの組み合わせでレコードは重複しないので、大丈夫だと思います」と説明された。「大丈夫って…では、なぜXの主キーにわざわざbとcが組み込まれているのでしょう」と問うと、「私が設計したわけではないんですが、その順に一覧したいからじゃないですかね」との返答だった。

私も現場で多くのDB構造を見かけますが、こういう話はよくあります。

特に、そのシステムの開発が終了して保守工程に移っているなど、予算的にも人員的にも、テーブルの見直しを提案しにくい現場では、現状の設計を前提として機能の追加や変更をしないといけません。

なので、私がデータ構造を設計するときは、そのあたりの事を考慮して設計をしているつもりですが。。。

 ようするに、DB設計というものは専門的な作業であって、局面毎に検討課題を切り分けるような工夫なしでは完遂できない。主キーとインデックスとは検討すべき局面が異なる課題で、これらを同時に考えればわかることもわからなくなる。レコードの並び順など、DB全体の主キーを確立したあとでゆっくり考えたらいい。

渡辺さんが書かれているように、DB設計という仕事が誰にでも出来る簡単なものでは無いという共通認識が無い現場だと、それもなかなか難しいです。

「ちゃちゃっと設計しといて」的なノリとでもいうのでしょうか?

DB設計の大切さ、難しさ、そして楽しさのようなものが、もっと広く認識されると良いなと思います。

 

 

↓ 応援クリックよろしくお願いします。

にほんブログ村 IT技術ブログ ITコンサルティングへ

名古屋のITカウンセラー。カウンセリング、悩み相談


関連記事

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

ピックアップ記事

11377367_830628453673686_5064112948466343003_n

2015.5.23

中部青年技術士会 環境ワーキングに参加

こんにちは。鈴木尚です。 今日は、中部青年技術士会の環境WGの活動でした。 天気は曇りでしたが、日差しがちょうど良い感じで、とて…

おすすめ記事

ツイッター

最近読んだ本

ページ上部へ戻る