主キーを設計するということ
主キーをその場その場でちゃちゃっと設計していませんか?
こんにちは。鈴木尚です。
渡辺幸三さんは、セミナーに参加させていただいたり、書籍を購入してサインまで(!)いただいた事もあるほど、学ばせていただいています。
その渡辺さんが先日、ブログに投稿されました。
{a,b,c,d}の複合主キーをもつテーブルXがある。ところが、別のテーブルYからテーブルXの特定レコードにアクセスする処理を見ると、{a,d}の参照キーでロジックが書かれている。bとcが抜けているのでバグではないかと問うと、「aとdの組み合わせでレコードは重複しないので、大丈夫だと思います」と説明された。「大丈夫って…では、なぜXの主キーにわざわざbとcが組み込まれているのでしょう」と問うと、「私が設計したわけではないんですが、その順に一覧したいからじゃないですかね」との返答だった。
私も現場で多くのDB構造を見かけますが、こういう話はよくあります。
特に、そのシステムの開発が終了して保守工程に移っているなど、予算的にも人員的にも、テーブルの見直しを提案しにくい現場では、現状の設計を前提として機能の追加や変更をしないといけません。
なので、私がデータ構造を設計するときは、そのあたりの事を考慮して設計をしているつもりですが。。。
ようするに、DB設計というものは専門的な作業であって、局面毎に検討課題を切り分けるような工夫なしでは完遂できない。主キーとインデックスとは検討すべき局面が異なる課題で、これらを同時に考えればわかることもわからなくなる。レコードの並び順など、DB全体の主キーを確立したあとでゆっくり考えたらいい。
渡辺さんが書かれているように、DB設計という仕事が誰にでも出来る簡単なものでは無いという共通認識が無い現場だと、それもなかなか難しいです。
「ちゃちゃっと設計しといて」的なノリとでもいうのでしょうか?
DB設計の大切さ、難しさ、そして楽しさのようなものが、もっと広く認識されると良いなと思います。
【楽天ブックスならいつでも送料無料】業務システムのための上流工程入門 [ 渡辺幸三 ] |
【楽天ブックスならいつでも送料無料】業務システムモデリング練習帳 [ 渡辺幸三 ] |
↓ 応援クリックよろしくお願いします。
名古屋のITエンジニア。カウンセリング、悩み相談
コメント
この記事へのトラックバックはありません。
この記事へのコメントはありません。