gemspec.infoのモック からの続きで、今回はER図を作りました。
設計成果
例によって成果物から。
Ruby on Rails プラグイン まとめ wikiのGemSpec.infoのER図がそのページです。
ER図の作図に使ったWWW SQL Designerにはエクスポート機能なんて機能はなく、スクリーンショット取るのもどうかと思ったので、使ったツールのデータファイルをそのままアップロードしてあります。
ER図で検討すべき事
先のエントリで言ったように、そのシステムで何が出来るか、どうやって処理するかはER図で検討すべきです。
まぁ、Webアプリの場合は(言語内の)オブジェクトはリクエスト毎に作り直されるのが普通なので、ユーザが入力したデータは、データベースに全て揃うはずですから、ER図を元に処理の方法を検討するのは道理なのかなと。
Railsの場合はActiveRecordが素晴らしいので、データベースの種類(MySQLなのかPostgreSQLなのかSQLiteなのか)は、あまり意識せずに設計できますが、高負荷になることがあらかじめ予想できたり、位置情報を扱いたい場合などは、設計当初からある程度絞り込んでおく必要がありそうです。
ちなみに、おいらの持っているイメージ(あくまでイメージであって真実ではないかも)
- SQLiteはぽん付けで設置したい時に使う。性能を期待してはいけない
- MySQLは最新版以外を使う価値は無いと思う。更新量が大きい場合に有効なクラスタリングのエンジンがあるので、そういう時には必ずMySQLを使う。それ以外ではPostgreSQLとあまり大差無いイメージ。
- PostgreSQLは必ずしもインストールされているモノではないが、過去のバージョンでもそれなりに使えるイメージがある。単体での性能が良いイメージを持っているので、スケールアウトではなくスケールアップを狙うならこちらかな。PostGISが素晴らしすぎるので、位置情報を扱うなら黙ってこちら。
RailsでERを設計するときの注意点
今まである程度ちゃんとした規模のシステムをRailsで作ったことがなかったんだけど、実際にgemspec.infoの設計をしてみて感じたことがいろいろあるので、 まとめてみます。
コードジェネレータの影響が大きい
まず驚いたことは、プラグインとかgemなどのジェネレータで作られるテーブルやリレーションの影響がかなり大きい事。まぁ、悪いことではなく、歓迎すべき事なんですけど、Rails使うとこんな感じなんだーと思って新鮮でした。
現時点でのgemspec.infoのER図では、7割ぐらいがジェネレータで作られるデータ構造をベースにしています。
うまく言葉にできないけど、データ構造を保持するテーブルではなく、リレーションをうまく使って機能を実現するテーブルの方が、ジェネレータによって作られる比率が高いように思えます。たとえば、ユーザ管理とか、お気に入りとか、タグ関係とか、コメントとか。
逆に、データ構造を保持するテーブル(今回で言えばrubygemsテーブルより右と下側)は、汎用性が無いのでジェネレータで作るのは難しそうです。
ジェネレートするより先にマイグレーション内容を知る必要がある
コードジェネレータの影響が大きいことは事実ですが、これが実作業の流れと反することになるのはちょっと痛かったです。
というのも、コードジェネレータで作られたテーブルも含め、全てのER図に書き出してみて初めて全体像が把握できるので、設計を固めるためには、コードジェネレータを動かしてコーディングを始めるより先に、マイグレーションファイルの内容を把握しておく必要があるからです。
特に上記の通り、よほど特殊なデータ構造でない限り、ジェネレータで作られるテーブルやリレーションの影響は大きいので、これを後回しにしたままERを作ってもあまり実になりません。同じような構造が2つできちゃって、完成時には不思議な構造になってたなんてことも起こる気がします。
おいら的解決法は、ここのようにあらかじめマイグレーションファイルの内容と動作を調べておいて、ER図の部品を作っておくことです。
この観点から見ると、WWW SQL Designerはインポート機能こそないものの、XMLを直接編集することでER図の部品を取り込むことが可能なので、結構使いやすかったです。(他のER作図ツールだとインポートできないモノもあると思います)
ER図を完成させないと全体像が掴めない
ちょっとクドイですが、先にER図を完成させておく必要性についてもうちょっと突っ込んでおきます。
コーディングを始める前にER図を完成させなければならない一番の理由は、先のエントリの通り、モックとER図を付き合わせて設計を煮詰めていくからです。
設計を煮詰めるにあたり、やはり可視化がきちんと出来ていないと漏れが出てしまって、効率的に作業できないように感じます。
ユーザインタフェースを改良したり、ワークフローまで立ち返って検討するって作業は、結構高次元の作業なので、いろんな事がぱっと見でわかることは重要だと思います。
特に、ER図の内容でそのシステムの限界(機能や性能)が決まってしまいますし、プラグインやgemの動作によって画面構成も変わってきますので。(作るのが楽になるような画面構成にするという意味も含む)
また、実際にモックやER図を煮詰める過程で、頭の中では必要なクラスやメソッド、その中で行う処理の概要をイメージしながら煮詰めています。
ER図の部品化とパターン化
さて、こんな感じでER図の設計を進めているのですが、これってRailsの流れからはちょっと外れるので、ER図の部品を作っておく必要があると述べました。
裏を返せばこの部品を作る作業は一人だけで良く、かつ部品は(ツールが同じであれば)みんなで共有できるので、プラグインの情報を扱うサイトとか、gemspec.infoのようにgemの情報を扱うサイトはかなり有用に思えます。(プラグインの情報が欲しい方はRuby on Rails プラグイン まとめ wikiの情報元あたりから調べ始めることをオススメします)
また、このへんを突き詰めていくと、「こういう用途には、このgemとこのプラグインの組み合わせで、ER図はこう、画面構成はこう」といったパターンも出来てくると思います。
ここまで整備できれば、設計はかなり効率化できると思うんですけどね。
個人的には、Railsを使う一番の強みはここなのかなと思っています。正に「設計 on Rails」
設計に使ったツール
最後に使ったツールについての紹介でも、と思ったんですが、これもRubyOnRailsの設計手法もレールに乗せよう で紹介しきっているので、リンクを張るに留めます。
極端な話、ツールはあまり重要ではなく、どちらかというと、ジェネレータで作られるマイグレーションファイルの内容をあらかじめ知っておくことの方が、設計作業上は重要な気がします。
あ、そうそう。WWW SQL Designerでポリモーフィック関連を表現するための線を引くには、データファイル(XML)のノードを直接編集する必要があります。このへんもうちょっと改良できればなぁと思います。(作者にソースもらってちょっと改良しようかなぁと思ったり思わなかったり)
0 件のコメント:
コメントを投稿