ER図の作成

前回、データベースの作成までは終わったので、

いざテーブルを作って・・・と動こうとしたものの構造を考えていなかった。

定義書から書いてーってのはダレる、仕事じゃないんだし、遊びだし。

ER図だけ書いとけば1クリックでDDLやら定義書起こしてくれるツールを使っちゃおう。

というわけで最初、Eclipseみたいなやたら重い開発環境を家のPCに突っ込みたくなかったので、

フリーのER図作成機能つきの開発ツールを落として作業してた。

これが見事に大失敗／(^o^)＼

使い勝手は良かったんだけど、CREATE SEQUENCE文を単体で書きたいのに

書き様がないという致命的欠陥。

DDLに出力させた後に手で追加するとかいうナンセンスは考えられんわ！

結果EclipseのpluginであるERMasterを使うことに変更して、

インストールやら手直しやらで時間掛かってしまった。

ほんまEclipseさまさまやで！

で、こうなった。

「おい、中央のテーブル外部キー貼りすぎでしょ、馬鹿じゃないの？死ぬの？」
とか言われそうだけど好みでこうなった。

他社に提供するシステムとかって、なんでこんなことするのってことが平気で発生するよね。
なんで対策してないの？→(ばかよけレベルの)ソース追加しろとなるフローが身に沁みてしまって、
基本外部キー貼って勝手なことすんなっていう造りにしておく精神になってしまった。
データ入れる前にちゃんと内容チェックして入れろや！って言いたい。
いやまぁ、今回私しか使わんから不要だけどね・・・。


他に荒れそうなのはサロゲートキーを使うあたりかなぁ。
複合主キーとなるテーブルは少ないし、
「どのデータとどのデータが紐付いているのかパッと見では超わからん」
というとても大きなデメリットがあるけど(サロゲートキー否定派はきっとコレが問題よね)、
コーディングしやすくなるんじゃないかなーと思う。きっと思ってるだけだけどね。
何より整然として綺麗に見える(結局は主観の話で、要は好み)ってのが大きいかな。

ここまで書きつつ外部キーについて調べつつしてる時に
CHECK制約なんていうものがあると初めて知った今日このごろ。
drop_item_listにCHECK制約を使うとなんと綺麗になることか！
これや、探し求めてたのは！

つーか、PostgreSQL文書のかなり初っ端の方に普通に書いてたわ。
なんで今まで知らんかったんか意味不なくらい。
基本他人の書いたソースから知識を得るコピペエンジニアらっちゃんは伊達じゃないわ。
一応、コピペした後ちゃんとソース理解して修得するからね・・・！(当たり前である)