我们目前有一个系统，我们的每个用户都有一个数据库。我们现在正在转向一个数据库多租户模式，因此一个数据库可以容纳许多客户。
几个问题：
是否存在多租户转换工具？或者它只是创建一个Tenant表并将一个添加TenantID到每个其他表的过程？
有没有一种简单的方法来实现多租户，而无需重构与数据库通信的代码？
我们有一个Odata.svc可以与数据库进行所有对话（我们的前端客户端范围从 .net 前端到 iOS 设备）。我阅读了一些关于使用 Federation 对tenantID谓词执行过滤的信息，因此根本不需要更改代码。这可能吗？
数据库中应该有多少租户有推荐的限制吗？
我收集这是一个愚蠢的问题（一根绳子有多长）。我们很可能会在 Azure 上托管最终解决方案。
期待任何人能给我的任何建议。我们正在对我们的流程进行根本性的改变，所以我想在我们处于它之下之前处于它之上。
自动化？
从理论上讲，应该可以制作一种工具，使执行这种令人生畏的操作（从单租户到多租户）变得更加容易。但是，鉴于此类产品的受众有限，我认为这样的工具并不存在。如果有一个浮出水面，那就太好了。
关于手动转换的想法
首先设计一个新的多租户数据库模式。（这意味着将所有单租户数据库模式与您可能拥有的任何共享模式合并。）我想让它像在设计时没有考虑遗留问题时那样。
您显然需要一个表，许多现有的带有列Tenant的单租户表都需要引用该表。Tenant_id例如，一个包含用户的表将需要它来唯一地将用户与租户相关联。
在一个简单Products表（Product_id作为主键）的情况下，应该可以添加一个Tenant_id列，生成一个具有复合键（Tenant_id和Product_id）的表。但是，如果您从头开始编写应用程序，我相信Product没有租户引用的表是正确的方法。这还允许租户共享产品，而不是添加重复项。因为一个租户可能有产品Product_id1,2,3 和另一个 1,2 你不能简单地合并表，因为你不能使用相同的 ID 两次——你需要唯一的主键值。解决此问题的一种方法是编写一个程序（使用 Java 或其他高级语言），将租户数据库中的所有数据读取到内存对象中，然后将数据写入多租户模式。对下一个租户数据库重复该过程，依此类推。这样你就会有Product_id值 1,2,3,4,5。一种快速而简单的方法是向每个模式中的所有 ID 值添加一个数字，例如 1,000、2,000 等等，然后简单地交叉手指以免出现冲突。
与数据库通信的代码
您将需要重写大多数数据库查询，以说明数据库现在是多租户的。这是一项艰巨的任务，特别是考虑到引入一个让一个租户摆弄另一个租户数据的错误的影响。然而，一些技术可以使这项任务更容易。例如，租户视图过滤器可以大大减少所需的工作量。
租户数量限制
我从未见过限制多租户结构中租户数量的建议。相反，多租户方法的优势在于其可扩展性。如今，您可以根据需要轻松创建数据库服务器集群或使用基于云的解决方案无缝添加更多硬件功能。
感兴趣的链接
老实说，根据我的经验，您无法自动执行此操作。您正在将非常重要的数据从您的基础设施转移到您的数据模型中。每个查询都是在假设租户已经建立的情况下编写的。因此，每个查询和 SP 都将更改为引用您的租户表并进行参数化。
您在 Q1 中询问您是否只是将tenantID 添加到每个表中。那将是一种方法，但不是我提倡的方法。它会导致您对不正确的数据敞开心扉（没有强制孩子与父母拥有相同的tenantID，甚至它们都相同！）您需要确定添加一个租户表，然后仔细选择哪些表需要参考它。不会是每个人。有些人会需要它，有些人可能出于性能原因选择将它放在那里。如果您决定使用后者，您无疑需要额外的检查机制来保持您的数据有意义。
如果您在 Oracle 中，您可以做的是将每个表重新加工成一个视图（仍然执行上述所有操作）然后将tenantID 填充到会话中并对其进行一些细粒度访问以隐藏大部分细节客户端。虽然很难做好，我不确定 SQL Server equivilent 是什么。可能值得一些研究。
合并数据库的原因是什么？您需要一些跨数据库报告或其他东西吗？否则，单租户有很多优势（多个升级和停机计划，性能可能会更好，具体取决于您的 [去] 规范化程度，单租户数据提取/报告的便利性，失去租户时的轻松移除）。云解决方案和单一租户可能会在这里对您有利。