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 に落ち着きました

いいよ！(╹◡╹)

ありがとうございました <(_ _)>