Web应用程序的基本数据库体系结构

Question

我正在尝试构建基于Web的任务管理系统。我希望不同的组织能够访问不同的任务列表。我可以通过两种方式来设置数据库体系结构：

1. 所有组织的所有任务都存储在一个表中。与组织X关联的任务记录具有为X的ID号存储的外键。
2. 每个组织都会收到自己的任务表。该表有一个前缀，用于将其标识为属于该组织。一个单独的表存储组织和表前缀之间的关联。

1. vs. 2的优点和缺点是什么？哪一个更好？此外，我正在考虑允许用户关闭和执行任务的某些属性，例如，能够跟踪您在任务上工作的时间。我想通过添加或删除任务表中的字段可以做到最好。但是，由于不同的组织将具有不同的配置设置，2。是否更适合此目的？

Answer 1

为每个组织提供自己的任务表并不是一个好主意。当新组织加入并且潜在的代码更改为从新表中读取时，这将需要物理数据库更改（尽管您可以动态更改前缀）。如果要在将来更改结构，也会产生更多开销，例如：添加新字段。这将限制您随着时间的推移重新设计和改进的能力。将负载分散到多个表上意味着您需要保持索引和其他类似的东西同步。由于涉及多个表，因此备份变得更加繁琐。

我原本认为最好的解决方案就是制作这个数据驱动，结构类似于下面的结构：

**OrganisationTable**
ORGANISATION_ID

**TaskTable**
TASK_TYPE

**TasksOrganisationStatusTable**
TASK_TYPE
STATUS (Boolean)
ORGANISATION_ID

**TasksTable**
ORGANISATION_ID
TASK_TYPE
DUE_DATE
etc.

通过这种方式，您可以动态更改活动任务，设置新组织等。在应用中使用缓存来提高性能。

Answer 2

此搜索词是“多租户数据库”或“多租户架构”。

有一个简短的概述和指向this StackOverflow question的有用文章的链接。

Answer 3

我做了这件事，我给每个“组织”自己的表，正如你所描述的那样。当新组首次访问该表支持的函数时，该表将作为基表的空副本即时创建。因此，只需要“维护”基础，如果它被更改，唯一的开销是（记住）删除婴儿表，以便可以根据更改的妈妈表重新创建它们。

在这种情况下，它的工作正常。