我们的平台应该由每个客户高度定制. (他们应该能够拥有自定义表并向现有表添加自定义字段).
在这种情况下,多数据库方法看起来很棒.
问题是.我的“用户”表应该在主数据库中还是在每个客户端数据库中？
用户可能拥有一个或多个组织,因此它将存在于多个数据库中.
那么,像国家表等通用表怎么样？
在master数据库中是有意义的.但是我有很多带有created_by字段的表,它们具有用户的外键.还有客户端的一些权限相关表.
如果有多个数据库,我会失去外键的强大功能,这意味着对数据库的查询更多.我知道我可以在数据库之间使用交叉连接,如果它们在同一台服务器中,那么我就失去了可扩展性. (我将来可能需要有多个数据库服务器).
我已经考虑了联邦表.不确定性能.
我使用的技术是PHP和symfony 2框架以及数据库的MysqL.
另外,我担心维护这样一个系统.我们可以创建一些脚本来自动化所有数据库中的模式更改,但是如果我们有10k客户端就意味着10k数据库.
你对此有何看法？
我的应用程序的主要特点应该是灵活性,所以如果客户需要比基本平台没有的更具体的东西,应该可以为他做.
解决方法
根据个人经验,如果您尝试在一台服务器上共享客户端,您会发现一个非常成功/活跃的用户将随着时间的推移占用该计算机的所有资源.我们在SAAS中有一个客户端破坏了共享服务器,我们不得不将他移到其他地方.
我会将全局枚举转换为服务.您可以为国家/地区列表,状态列表等创建一个中央数据库,并将其置于Web服务层之后.此外,在该数据库中,您可以拥有用户管理/管理哪些服务器属于哪个用户等.您可以创建一个管理门户,读取/写入此数据库以管理您的用户群.
如果我再次做SAAS,我会从小处开始,等待疼痛发作.你真正想要的是在它们发生时解决扩展问题的好工具.让一些脚本准备好跨服务器进行滚动模式更改(一旦有多个服务器,就无法避免这种情况).在修改模式时使用脚本来删除计算机.有脚本将用户从共享服务器迁移到专用服务器.
考虑从中央数据库设置复制.这将抽取每个用户分区/数据库所需的全局信息,而无需编写大量代码.
但是我见过的最重要的建议 – 并且经验丰富 – 不要太努力建立下一个规模的Facebook.开始简单,看看实际发生了什么,然后再担心主要的可伸缩性问题.您可能会感到惊讶,因为用户群的增长可以很好地扩展,哪些不可扩展.
