背景
构建一个用户可以通过任何计算机访问的
online information systemwww.example.comwww.example.com我是否需要为每所大学拥有单独的员工表，或者可以拥有一个包含大学 ID 列的表吗？
我认为第二是最好的，但假设我有 20 所大学或组织，总共有数千名员工。
最好的方法是什么？
所有桌子都一样吗？这只是给你举个例子。
谢谢
该方法将取决于数据、使用情况和客户要求/限制。
按照 duffymo 的建议，使用集成模型。如果每个组织都是一个更大整体的一部分（即所有大学都是州立大学董事会的一部分）并且对跨查询访问的安全性担忧最小2，那么这可能是合适的。这种方法在每个组织之间具有最小程度的分离，因为相同的模式1 和关系是“公开”共享的。它最初会导致一个非常简单的模型，但如果需要组织特定值的关系，它可以变得非常复杂（使用复合 FK 并正确使用此类模型），因为它增加了数据的另一个维度。
实施多租户。这可以通过关系上的隐式过滤器（可能隐藏在视图和存储过程后面）、不同的模式或其他特定于数据库的支持来实现。根据实现的不同，即使所有数据可能驻留在同一个数据库中，这也可能会也可能不会共享模式或关系。通过隐式隔离，可以隐藏/消除一些复杂的键或关系。多租户隔离通常也会使交叉查询变得更困难/不可能。
完全隔离数据库。每个客户或“组织”都有一个单独的数据库。这意味着单独的关系和模式组。我发现这种方法使用自动化工具相对简单，但它确实需要管理多个数据库。直接交叉查询是不可能的，但如果有需要可以使用“链接数据库”。
尽管它不是“单个数据库”，但在我们的例子中，我们有以下限制：1）不允许在组织之间共享/公开数据，2）每个组织都想要自己的本地数据库。因此，我们的产品最终采用了筒仓方法。确保所选方法满足客户要求。
只要正确规划索引和查询，这些方法都不会对“数千”、“数十万”甚至“数百万”记录有任何问题。然而，从一种方式切换到另一种方式可能会违反许多假设的约束，因此应该尽早做出决定。
1 在此响应中，我使用“架构”来指代数据库对象（例如表、视图）的安全分组，而不是数据库模型本身。实际使用的数据库模型可以是通用/共享的，就像我们在使用单独的数据库时所做的那样。
2 集成方法不一定不安全 - 但它本质上并不具有其他设计的一些内置隔离。
我会将其标准化为具有 UNIVERSITY 和 EMPLOYEE 表，它们之间具有一对多关系。
您必须注意确保只有与特定大学相关的人员才能看到他们的数据。基于角色的访问将很重要。
这称为多租户架构。你应该读一下这个：
http://msdn.microsoft.com/en-us/library/aa479086.aspx
我会选择 Tenant Per Schema，这意味着跨不同的 schema 复制结构，但是，由于您应该将所有 SQL DDL 保留在源代码管理中，因此编写脚本非常容易。
如果在同一张表中进行所有操作，很容易搞砸并在租户之间“泄露”信息。