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