2012-02-18 75 views
14

我目前正在设计一个Web应用程序,我将客户注册为公司。每家公司都有自己的一套用户。正如我在设计这个,我想知道哪种方法最适合。我看到像使用子域名的fogbugz或basecamp这样的网站。在子域的情况下,您是否有每个子域的数据库实例?我想知道是否建议每个公司都有一个数据库实例,或者如果我应该有某种公司表并且从一个数据库管理公司和用户数据/凭据。构建一个具有多个数据库实例或仅仅一个实例的Web应用程序

哪种方法最好?有关于此主题的文献(即任何网页或书籍)?

在此先感谢!

+4

每个选项都有其优点。单独的数据库意味着更多的补丁/修复/更新维护,更多的管理开销。但它也意味着更容易分离数据,通过将用户分割到不同的数据库服务器更容易进行扩展。这实际上取决于你的最终目标和要求是什么。你的问题没有银弹。每个决定都有两个方面,其中一些确实是50/50,然后你选择并继续前进。只需评估你的需求是什么以及哪种解决方案最适合这些需求。 – xQbert 2012-02-18 18:13:14

+0

我第二个xQbert在那。例如,对于我们正在构建的应用程序,业务用户看不到其他人的数据非常关键。将它们保存在单个数据库中时,在测试中未检测到导致租户之间泄漏的错误的风险总是较高。 – user3141326 2015-08-12 07:20:09

回答

17

你必须权衡你的选择,因为其中一些将是一个意见问题,可能不适合你的实施。

话虽这么说,我会考虑的单一数据库的做法,原因如下:

  1. 维护:运行每个注册的“客户”数据库时,你会很容易到达的情况下您对应用程序模式所做的任何更改或升级都必须应用于每个数据库实例。这会变得荒谬,快速。

  2. 便利性:您可能需要分析和使用统计信息,或某种方式来管理所有这些数据库。试图为所有数据库聚合相同的查询,查询单个数据库相对比较简单。这不会成比例。

  3. 可伸缩性 *:如2所述,您将需要一种特殊的聚合来查询有关您的客户端以及您的应用程序的整体情况。您的应用程序越大,查询就越复杂。另一个问题是,如果一个客户比另一个客户更多地使用应用程序,您会鼓励什么来优化?你的应用,更大的客户数据库,还是更小的客户?不要忘记你所做的任何更改都必须复制到所有数据库。

  4. 备份:您可以轻松地备份一个数据库,只需创建一个转储并将其存储在某个地方即可。获得一千个客户端,现在您必须运行1000个数据库转储,并将其命名为足以在单个数据库损坏时识别它们。你怎么知道这是否发生?数据库错误将被本地化为特定的一个,而不是整个应用程序。

  5. UI:用户注册或被邀请使用您的应用程序,并且属于一个特定的客户端。你打算将该用户帐户保存到客户端的数据库吗?如果是这样,请参阅用户想要更改其密码时使用该数据的问题的可伸缩性,或者要通过电子邮件发送该数据。那么,你是否告诉用户让你知道他们在哪个数据库中,以便找到它们?

  6. 简化:每个客户端都有一个数据库,并且只想使用一个数据库。你如何将它们合并在一起而不会显着破坏事物?如果使用自动递增的ID,将会出现主键冲突;如果您决定重新生成密钥,添加书签的网址将会中断;跨表的外键将不再指向正确的记录。您的数据完整性将下降。

您提到了通过自定义子域名提供其产品的“白色标签”服务。我不知道这些是如何工作的,但子域只是其DNS域文件中的基本CNAME或A记录。可以自动添加这些子域,应用程序的设计和一些服务器配置可以处理将这些子域链接到正确的账户和数据。他们只是网址,所以也许在后端,应用程序不区分之间:

http://client.example.com 
http://example.com/client 

总体来说,你可以决定所有这些问题都是事情可以宁可处理。然而,要警告的是,通过这样做,你可能会在自己的脚下开枪,并且通过制定精心设计的单一数据库模式和抽象前端,可以获得更多。

* @ xQbert提到多个数据库的可伸缩性带来的真正好处。我已经修改了这个答案,以澄清我更关心其他方面。

+1

感谢fuzzyDunlop提供了非常透彻的答案。我非常倾向于这样做,但开始猜测自己。好像我正朝着正确的方向前进 – ralph 2012-02-18 23:08:00

相关问题