我有一个简短的概念性问题:
最近,我开始开发一个应用程序,我可以在其中(即时)创建客户,而这些客户反过来可以创建具有许多其他内容(自己的登录名等)的项目。
URL 结构是“example.com/client1/project1”,供用户访问他们的项目。到目前为止一切顺利,我用 DB-Model 和路由等管理了这一切。
示例结构:
-> Client -> Project -> User
-> Forum -> Topic -> Post
-> Message
-> Setting
-> [...] (you get the gist)
但是,只有少数客户端(< 15),所以我想知道为每个客户端使用单独的应用程序文件夹和数据库是否更好。因为这样,我还可以分别为每个客户端推出升级。
这是我对此事的初步想法(进行单独安装):
专业版:单独的应用程序
- Ability to roll-out updates and new features separately for each client (it may well be that some new features are unwelcome by some clients)
- An error in one DB will only affect one client
Contra: Separate Apps
- More maintenance work in terms of monitoring all apps & applying updates globally (but given the number of clients this is not really a problem)
- May become really confusing with different versions etc.
- No ability to implement a superadmin that can access all apps (needs to be done on app-level)
- Harder to create shared functionality and data (e.g. billing for clients)
- Bad practice?
如果我希望合并所有安装,那么这真的不是问题,因为一切都基于 UUID。此外,我仍将实现客户端模型,其余的都依赖于它:这样,只需将数据库和客户端文件组合到一个应用程序安装中(假设每个人都想要相同的功能) .
注意:CakePHP 核心库在任何情况下都会被共享:所以这不是这里的问题。
在这种情况下你会怎么想?我能看到的唯一问题是计费:
但是从每个客户端调用中央数据库让它知道“嘿,我刚刚创建了一些需要计费的东西”,这不是问题。
如果我在单个应用程序中执行此操作 - 如何从某些更新中排除某些客户端?还是我应该简单地强迫每个人习惯任何新功能?