画面からERD (続き)
id:habuakihiroさんコメントありがとうございます。
デブサミおつかれさまでした。おかげさまで今自分の中でERDがブームです。はっきりいって、プログラム側で何とかなるならDB設計は適当でもいいかななんてなめてたんですが、最近ERDの面白さに目覚めてきつつあります。
いいんです。人生に遅すぎることなんてないんです。偉い人にはそれがわからんのです。
もし時間があれば、IDなしでコードをそのまま主キーにして、交差エンティティもなしで書いてみてください。比較してみると面白いです。
メンバの1人が先にやってた分が、まさにそんな感じでした。
マージ作業の時に、比較しながらて詰めてたんですがそんとき思った感想は↓。
- 従来方式は、SELECT,INSERT,UPDATEがしやすそうだなーと思う自分がいる。
- SQLのスキルアップが必要だということですね。orz
- 1対多は、交差エンティティなしで書くのがやっぱりすっきり見えるなぁ。
- ABD的に交差エンティティをうまく抽出できると、全体の構造はとてもきれいに見える。
- FKだけしかない交差エンティティを抽出できるとちょっと快感。
- IDを単なるポインタとして設計する、という部分は断然こっちの方がいい！きれい！
- 交差エンティティは、単にエンティティ間を結んでるものと(ユーザとグループの対応関係のようなイメージ)、アクティビティっぽいものに2分されてるようになった。
- ただ、アクティビティっぽい交差エンティティに、FKじゃない項目が最後まで残ってしまった。
- 「実行日時」とかなんだけど、これをIDと実行日時を持つ別エンティティに切り出してそのFKを交差エンティティにいれる、というところまで原理主義をとるだけの根拠というかなんというか、思い切れないわけで。まあ、そこは妥協。
- ただ、アクティビティっぽい交差エンティティに、FKじゃない項目が最後まで残ってしまった。
性能に関しては、indexの張り方でどうとでもなります。
こころ強いお言葉です。
IDをプログラムで使うか、ということについては、マジックナンバーはあり得ない（＝分岐になるんだからエンティティを分けられるはず）ですが、キャッシュしてあるIDでレコードを狙いに行くのは全然問題ないです。Cでポインタ使うのと同じ感覚でOKです。
了解です。安心して使えます。
本音を言うと
マジックナンバーはあり得ない（＝分岐になるんだからエンティティを分けられるはず）
がまだ消化不良なんですが、ああそうねぇ、と思えるように精進します。
さて、今日のマージ作業の結果、そこそこキレイな構造になったんじゃないかとほくそえんでますが、明日のレビューでなんといわれるやら。
根がエレガント指向なので、キレイ構造万歳！なんですが、そのテーブルってどうやってINESRT,UPDATEすんの？っていわれたムムム…となってしまう2重拘束の罠。というか、単なる経験不足。
- 交差エンティティにレコードをINSERTするためには、ドメインとしてのエンティティ(という言い方でいいのかな?)のIDを知らないといけない。例えばPostgreSQLのserial型とかでINSERT時に自動採番する方式をとってしまうと、たった今INSERTしたレコードのIDをプログラム側では知ることができない →交差エンティティにINSERTできない →( ﾟДﾟ)ﾏｽﾞｰ
- CREATE SEQUENCEで作ったシーケンスから直接 SELECT nextval()して、INSERTするレコード用のIDを前払いしてもらってから、ID値をSQLで明示指定して各種テーブルにINSERTしていくという方式になるのかな。排他制御のために忘れずにLOCKしないといけないな。
- 交差エンティティを介して結合される情報を新しくINSERTする場合、少なくとも3回はINSERT文を発行しなければならないのか。
- シンプルなSQLを数回発行するだけなんでそんな大変なことでもないけど。
- それとも、DB側にプロシジャを用意して、プログラム側では一発だけでOKとした方がいい？
うーむ。この圧倒的な素振り不足感がたまりませんな。
