ムダに頑張らないプロジェクトマネジメントを目指そう！

• 2014.8.28
• ＩＴ
• データモデリング
• コメントを書く

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

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

こんにちは。鈴木尚です。

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

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

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

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

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

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

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

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

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

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

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

名古屋のＩＴエンジニア。カウンセリング、悩み相談