多个客户端的 SQL 数据库共享答案

【问题标题】：SQL Database Sharing For Multiple Clients多个客户端的 SQL 数据库共享
【发布时间】：2011-05-09 00:50:15
【问题描述】：

我正在创建一个具有 SQL Server 后端的 iPad 应用程序。我的问题是，我应该在每个客户注册时为他们创建一个新数据库更好，还是应该创建一个 SQL 脚本，在客户注册时为他们生成新表。

例如场景 1 每个用户一个数据库。对于 100 个用户，sql server 将有 100 个单独的数据库。即User1_DB，User2_DB......

场景 2 每个用户的新表集。对于 100 个用户，sql server 将在同一个数据库中拥有 100 个单独的表集。例如MyiPad 数据库 - Table1_User1、Table2_User1、Table1_User2、Table2_User2

在这两种情况下，我们都会有自动脚本在用户注册时生成表格/数据库。

所以我的问题是什么场景更有效？或者两种情况都是错误的，因此我应该如何解决这个问题？

提前致谢

【问题讨论】：

【解决方案1】：

我会说，除非您明确需要进行如此多的分离，否则我建议您使用一组表并使用带有客户 ID 的客户表来区分客户数据。您仍然可以通过存储过程限制对数据库的访问，这样客户就无法看到其他客户的数据，但您不必处理多个数据库或数千个表的所有开销。

但是，如果您必须进行分离，请使用不同的数据库。数据库分离使您能够更好地控制数据安全。如果您必须竭尽全力为每个客户使用不同的对象，那么您需要单独数据库的完全安全性。这还将为您提供将一个客户转移到另一台服务器等所需的可移植性。

已经有一个关于 SO 的类似问题，他们遵循了我的基本建议。基本上，Wordpress 一开始只使用一个数据库，但随着规模的扩大，最终每个客户都使用一个数据库，这样他们也可以向外扩展。这是链接：

【讨论】：

数据库将有超过 60 个表来管理行级分离，这将是一场噩梦。我认为这将是每个用户的单独数据库。一个 SQL Server 机器上的 100 个独立数据库与一个 SQL Server 上的一个数据库中的 100 个用户数据之间是否存在性能差异？
此外，可扩展性和可移植性也是一个巨大的因素，它引导我更倾向于每个用户单独的数据库。
@HackAndSlasher - 在这种情况下，您最好为每个客户提供一个单独的数据库。对于小型实现来说，这是一种艰难的方式，但如果你变得更大，它会更容易处理。
60 张桌子是一场噩梦？孩子们的工作，认真的。大多数应用程序有超过 60 个表，程序员得到报酬以使它们按需要工作。这与噩梦相去甚远......假期更像是它。

【解决方案2】：

我根本不会走这条路，而是在行级别上做，每个表的每一行都绑定到特定用户（或公司/用户，如果应用程序可以为特定公司注册有很多用户）。对于大量用户而言，创建单独的表/数据库根本无法扩展。

【讨论】：