mysql - 该 SaaS 的最佳数据库结构

Question

我想通过这篇文章开始集思广益......在提出我的问题之前，让我先进入场景:

我将构建一个软件服务，它将是一个类似 CRM 的基于网络的软件。
因此，每个人都可以订阅该服务，并且作为登录用户，您可以拥有一名或多名联系人和一名或多名员工(员工也可以登录)。

该软件以联系人为中心......每个联系人都可以拥有项目、文档等。

现在的问题是: 为了构建一个安全且易于维护的软件，这次我想到了使用单独的数据库。您对为每个订阅者建立一个专用数据库有何看法？

为什么我会问这个问题？ 嗯...该服务将有一个自定义版本。这意味着单个用户(已订阅该服务)可以拥有非常非常个性化的版本，这种定制将触及每一层:

• 数据库结构
• 模型类
• View (这是最简单的部分)
• Controller

似乎这将是一个不同的应用程序。

我正在考虑保留一个所有用户都可以登录的主数据库......然后连接到他们的私有(private)数据库。

我看到很多服务也使用个人登录页面，具有第三级域名，例如:yourcompany.service.com

查看他们的网址，似乎他们使用了这种方法，因为我们可以找到类似这样的内容:

yourcompany.service.com/contact/1

显示单个(第一个)联系人(ID 1)的详细信息页面。 看来这是联系人表的第一条记录。

否则，我可以保留一个数据库并使用 user_id 控制一切。因此，例如，使用一个联系人表来存储我的所有用户的所有联系人……并仅在需要时编写自定义表。

我陷入困境......我曾经在一个应用程序中使用过一个数据库，但我想有机会采用另一种方法。

你有遇到过这个问题吗？ 你会如何解决这个问题？

Answer 1

像这样的大多数所有者操作系统(而不是用户操作)使用 Multi-Tenancy (多客户)数据库，而不是每个客户单独的数据库。这是因为管理较少的数据库实例可以产生显着的规模经济。 (换句话说，为每个客户管理一组单独的 table 是一个巨大且无法扩展的痛苦。)

WordPress 是两者的一个有趣的例子。他们有一个多站点系统，其中多个不同的用户共享一个数据库。他们在 SaaS WordPress.com 系统上使用它。它们还具有单一站点配置，各个用户可以自行管理。