のCakePHPのApp-構造：1 DB＆アプリの対複数のDB＆アプリ

Question

私は簡単な概念質問があります。最近

は、私が（その場で）人のクライアントを作成することが可能なアプリの開発に着手し、他の多くのもの（独自のログインなど）を持つプロジェクトを作成することができます。

URL構造は、ユーザーがプロジェクトにアクセスするための "example.com/client1/project1"です。これまでのところ、私は、DB-モデルとそれをすべてとても良い管理およびなど

例の構造ルーティング：

-> Client -> Project -> User 
        -> Forum -> Topic -> Post 
        -> Message 
        -> Setting 
        -> [...] (you get the gist) 

をしかし、だけなので、クライアントの一握り（< 15）が存在します私はそれが各クライアントのために別個のapp-folderとDBを使う方が良いのだろうかと思っていました。このように、クライアントごとに個別にアップグレードを展開することもできます。ここで

---

（個別にインストールのために行く）問題に関する私の最初の考え：

プロ：ロールアウトするためのアップデートや新機能を個別に各クライアントに対して別々のアプリ

• 能力（いくつかの新しい機能が一部のクライアントにとって歓迎されないことがあります）
• 1つのDBのエラーは1つのクライアントにのみ影響します。

コントラ：セパレートグローバルアプリすべてのアプリケーションを監視&適用するアップデートの面で

• もっと保守作業（ただし、クライアントの数与えられ、これは本当に問題ではありません）
• が本当になるかもしれません他のバージョンと混同するなど
• すべてのアプリにアクセスできるスーパー管理者を実装する能力がありません（アプリレベルで実行する必要があります）
• 共有機能を作成するのが難しい（例えば、クライアントの請求）
• 悪い練習ですか？

---

私が今までは、すべてのインストールをマージしたいべきすべてがUUIDに基づいているので、これは、実際に問題になることはありません。さらに、私は依然としてクライアントモデルを実装して残りのすべてを依存しています：この方法では、データベースとクライアントのファイルを1つのアプリケーションインストールに結合するだけです（すべての人が同じ機能を望む場合） 。

注：CakePHPコアライブラリはどのような場合でも共有されます：これはここでは問題ではありません。

この場合、あなたはどう思いますか？私が見ることができる唯一の問題は請求である：

しかし、各クライアント内から中央DBを呼び出して、「おい、私はちょうど請求する必要があるものを作った」と言っても問題ありません。

アプリで行う場合 - 一部のクライアントを一部のアップデートから除外するにはどうすればよいですか？それとも、誰もが新しい機能に慣れさせるだけでいいのですか？

Answer 1

オーバーヘッドがあるため、絶対に必要な要件があった場合は、「別のアプリ」に行きます。

EDIT： あなたは、これをキックオフのための多くのおかげで、クライアント