我们正在考虑使用单个 SQL Server 数据库来存储多个客户端的数据。我们认为将所有数据放在一个数据库中可以使事情比“每个客户端单独的数据库”设置更易于管理。
我们最大的担忧是意外访问错误的客户端。如果我们不小心将一个客户的数据显示给另一个客户，那将是非常非常糟糕的。我们执行了很多查询，并且害怕有人说“给我写一个关于这个和这个的查询，以便在 15 分钟内向客户展示会议。” 如果有人粗心并忽略了WHERE过滤正确客户的子句，那么我们将遇到严重的麻烦。SQL Server 是否有强大的设置或设计模式，使得不可能（或至少非常困难）意外地从单个“全局”数据库中提取错误的客户端数据？
需要明确的是，这不是客户直接或通过应用程序使用的数据库（目前）。我们正在谈论由我们的几个程序员访问的数据库，我们害怕搞砸自己。
至少，您应该将客户端数据放在单独的模式中。在 SQL Server 中，架构是授权单位。只有为给定客户授权的人才能看到该客户的数据。除了其他保护之外，您还应该使用数据库的内置授权功能。
现在，听起来您处于这样一种情况，即一小部分人正在为每个人访问所有数据。好吧，如果你成功了，那么你将来可能需要更多的人。事实上，您可能会让一些客户直接访问数据。如果是他们的数据，他们会希望应用程序在其上运行。
如果您计划增长，我最好的建议是将每个客户的数据放在单独的数据库中。我将构建系统，以便该数据库可以位于远程服务器上。如果它需要与公共数据同步，则开发一种复制策略来移动该数据。
您可能认为让一个客户看到另一个客户的数据是不好的。从商业角度来看，这是致命的——就像“公司倒闭，没有工作”一样致命。您的客户可能比您更关心这种保密性。而且，确保保护的架构将使他们更加舒适。
多租户数据架构 http://msdn.microsoft.com/en-us/library/aa479086.aspx
这就是我们所做的（不幸的是mysql）：
假设您所有的 DDL 都在源代码控制下的 .sql 文件中（应该是这样），那么拥有许多数据库或模式并不是那么困难。
[1] mysql 中的模式称为“数据库”
您可以为每个表设置一个内联表值函数，该函数采用必需的参数@customerID并将该特定表过滤到该客户的数据。如果整个应用程序仅使用这些 TVP，则该应用程序在构造上将是安全的。
可能会有一些性能影响。确切的数字取决于架构和查询。但是，它们可以为零，因为内联 TVP 与查询的其余部分一起内联和优化。
您只能通过带有强制性 customerid 参数的存储过程来限制对数据的访问。如果您允许您 IT 构建视图，迟早有人会忘记您所说的 where 子句。但是，每个客户的模式已经预先过滤了视图，这将启用自助服务和额外的价值，我猜。