現状、「OpenPNE（１）」と「OpenPNEの会員データと連動したWebデータベースアプリ（２）」が動いているコンシューマ向けサイトがあります。
ここに、私が別の「Webデータベースアプリ（３）」を、yoshukiさんが別の「携帯対応フォーラムアプリ（４）」を追加で作る予定があります。
- （１）、（２）は前担当会社のシステム（PHP）でありこれからサーバー毎引き継ぐ。
- 1年前から周辺システムはRailsで統一されつつある。
- サイト全体を今後、継続的に開発していく予定にある。
- お客さんの優先順位の第一位は（３）を期間内に立ち上げる事
- （１）はクローズしてもかまわない事。
- とは言え出来ることなら既存会員データは残したい。（俺の思惑）
- 工期に余裕はない。（まっさらから３を作る分しかない）
みなさんなら会員データ周りをどのように設計しますか？
俺が考えた選択肢：
- （１）、（２）の会員テーブルを見るようにして（３）、（４）を作る。
- （３）、（４）ともに新規に作る（データ連携無し）
- （３）と（４）は同一会員データで作る（１、２との連携は無し）
- （３）、（４）を作った後で（１）、（２）をそれにあわせるように改修する。
- （３）、（４）を作った後で（１）はクローズ、（２）は改修する。
- 認証サーバ的なものを作る。
俺の中のSIer人格：
「お客さんから必要十分条件は提示されている。当然2だ。どんなシステムも段階的改修が可能である。ストアドプロシージャ、変換スクリプト、バッチ等で次フェーズ以降でのシステム統合を目指せばよい。」
俺の中の楽観主義者：
「5でしょ！きょうびほとんど使われて無いOpenPNE維持してもコストかさむだけでしょ！（２）をRailsで作り直して新機能を作ろう！」
俺の中の潔癖主義者：
「6が正しい。OpenIDサーバーを作り、全てのサービスを対応させる。authorizeとauthenticateは別である。」
俺の中の事無かれ主義者：
「前の会社がOpenPNEに合わせたんだから僕らも1だよ。PHPで作れば環境も合わせられるし」
まあ、おまいら（俺ら）の言い分もわかるが・・・。