EclipseのプラグインClayについて
EclipseのプラグインClayについて「Railsでどのように開発に使っていますか？」という質問メールが来てさらっと回答しようとおもったら長くなったのでエントリーにしました。
私の場合、Clayはモデル図の出力のためというよりは、DB設計の初期の段階で使っているという感じです。
ClayはDBからリバースしてモデル図を出力することもできますが、その場合、テーブル間の関連は失われてしまうようです。（その辺は無料のツールなので贅沢と割り切り）
Rails用のリバースならRails Schema Browserとか今後に期待しています。
http://tomtenthij.nl/2008/2/12/rails-schema-browser-plugin-proof-of-concept
Clayでは逆にGUIでテーブルと関連、インデックスなどを書いて、それがSQLに吐き出せるのでそちらの機能を主に使っています。なのでRailsと連携というよりは、開発環境に設計＆SQL生成ツールがついたと思っていただいたほうが良いかと思います。Railsと連携というよりはDBを使った開発全般向けです。テーブルが数十個とかになってくると関連を覚えておくだけでも大変ですからね。また、RailsにはMigrationという非常に便利なDBスキーマ管理ツールがありますが、「Migrationによるスキーマ管理」と「Clay(というよりER図によるスキーマ管理)」はそれほど相性の良いツールではありません。
私の場合は次のような使いかたをしています。
（最初想定するテーブルが数十とかもっと多いことになることが予想できるような場合です。少ない時はMigrateionだけでOKじゃないかと思います）
（MySQLの場合SOURCEコマンドなどでファイル指定）
- プログラムを書く
開発の初期はある程度これでやってしまいます。
特にRailsに限った話。
- Scaffold(Restfulな)などが使いたい場合は--skip-migrationオプションを付けるとmigrationファイルの生成を止めることができます。
- 現状のスキーマからMigrationファイルを作りたいときは、rake db:schema:dumpを実行するとdb/schema.rbを生成することができますのでこれをdb/migrate/001_initial_schema.rbなどにコピーします。もちろんこのとき001_initial_schema.rbには全てのテーブルの情報が入ります。その後、rake db:migrate OR rake db:migrate:resetでDBに反映させることもできます。
- 最初の公開環境へのDeploy後はClayを使うのを基本的にやめてます。それ以降は通常のRailsの開発の流儀にしたがって、db/migrate/002_xxx.rbといったファイルを作り始める。公開後のスキーマ変更のための差分ファイルがなければ困りますよね？そうしなければcapistranoによるdeployの恩恵がほとんどなくなります。
Railsの正しい（一般的な？）開発は、最初からMigrationを使うことかもしれません。ただし、db:migrate:resetしても良いような時期（公開前）はスキーマの変更がものすごくたくさん発生するので、Migrationファイルは大量にできてしまいます。
公開もしてない仕様も固まってないような開発の初期からMigrationを使うとMigrationのバージョンがあがりすぎて、どのMigrationでどうSchemaが変更されているかがわからなくなってきたりします。migrationファイルが100個ぐらいになってくるとスキーマの変更を追っていくのがかなり大変になります。
そういうのを避けたい場合には最初に設計図とスキーマ(後のdb/schema.rb)を一致させておくというのは頭の整理に多少役立ちます。
あと、Railsの場合、ほとんどの人が一人で開発したりするんじゃないかと思ったりするんですが、複数人で開発する場合には、初期の意志疎通には図があると重宝します。
なお、私もこの通りにやっているばかりではなく、その辺は臨機応変です。WindowsやUbuntuでEclipseを使ってたときはClayも動いたけど、最近はCentOS上で開発することが多くて、CentOSでは動いてません。（Javaのバージョンとかその程度だとおもうんだけど、調べてません。）
何年もEclipseを使ってますが、Eclipseのプラグインのなかではできの良いDB設計ツールだと思います。
