Date post: | 30-Jun-2015 |
Category: |
Software |
Upload: | kosuke-komiya |
View: | 588 times |
Download: | 0 times |
MySQL Workbench and ERD.
MySQL Casual Talks in Fukuoka vol.4 / 2014-10-21 Kosuke Komiya
@komiyak
こんばんは!
自己紹介
@komiyak
お友達からお願い致します(╹◡╹)
今日は ERD(Entity Relationship Diagram)
と MySQL Workbench
突然ですが
–某V氏 Twitter より
“大規模(100万行以上)なソフトウェアを 破綻せずに開発するにはどうしたらいいか?”
ドキュメントを書くこと
個人的な見解ですが
理由
• 設計は、関連する情報を頭に入れた状態でパズルのピースがあう場所を探していくような作業
• できるだけ多くの情報を処理したいが、残念ながら人には無限の記憶力がない…
• 1000行のコードは覚えられるが
• 1,000,000行のコードを覚えておくことはできない
• 記憶力はスケールしない!
そのため、 問題を小さく保つ必要がある
(小さな機能、小さな要素の塊にする)
さらに突き詰めると..?
• 小さな機能といえども、それが増え続けると
• 膨大な量になり、やはり覚えておくことはできない
• 覚えていることに頼らない
常に、その問題について 知らない(忘れている)状態からスタートする前提
自分が作ったものであれ、他人が作ったものであれ
• 機能に取り組むたびに、周辺のコードを読む
• コードは正確だが、読むコストが高い
• 読むコスト(理解するコスト)を下げたい
理解を助けるもの → ドキュメント
ERD(Entity Relationship Diagram)
ERD• アプリケーションのスキーマを、できるだけ明確に説明するための役割がある。
• たくさんの関連テーブルがあるとき、その関連性を説明する資料になる。
• > desc users;
• そこには明確な関係性はなく、ただ想像するしかない。( ゚皿゚)キーッ!!
ERD 書くの大切 (※自戒を込めて)
長い前置きはここまで
ERD 書くとき何使うか
気になる所
• 各テーブルの情報がわかりやすけりゃいい
• 人と共有する(できれば編集も)
• 特定ベンダーのツールでもいいが、急に開発中止とかはイヤだなー
一時期、いろいろ試してみました
• Excel
• Google Spreadsheets
• Google Drawings (Cacoo みたいに使えるし、表も出せる)
• ERMaser(Eclipse ..(́Д`))
• MySQL Workbench
結局 MySQL Workbench に落ち着きました
いいよ!(╹◡╹)
ありがとうございました <(_ _)>