当前，我们有一个系统，每个用户都可以获取一个数据库。现在，我们正在迁移到一个数据库 Multi-Tenancy 架构，以便一个数据库可以容纳许多客户。
几个问题:
Tenant表并将TenantID添加到其他所有表的过程？我们有一个
Odata.svc，它可以与数据库进行所有对话(我们的前端客户端的范围从.net前端到iOS设备)。我读了一些有关使用Federation对tenantID谓词执行过滤的知识，因此根本不需要更改代码。这可能吗？我正在收集这是一个愚蠢的问题(一根线要花多长时间)。我们很可能会在Azure上托管最终解决方案。
期待任何人都能给我的建议。我们正在对我们的流程进行根本性的更改，因此我想在此之前先掌握它。
最佳答案
自动化吗？
从理论上讲，应该有可能设计出一种工具，使其更容易执行此艰巨的操作(从单租户到 Multi-Tenancy )。但是，鉴于此类产品的受众有限，我认为这种工具不存在。如果一个浮出水面，那就太好了。
关于手动转换的想法
首先设计一个新的 Multi-Tenancy 数据库架构。 (这意味着将所有单租户数据库架构与您可能拥有的任何共享架构合并。)我想让它看起来像是在设计时不考虑遗留问题的情况。
您显然需要一个Tenant表，许多现有的带有Tenant_id列的单租户表都需要引用该表。例如，带有用户的表将要求此表将用户与租户唯一地关联。
对于简单的Products表(以Product_id作为主键)，应该可以添加Tenant_id列，从而产生带有复合键的表(Tenant_id和Product_id)。但是，如果您从头开始编写应用程序，我相信没有租户引用的Product表是正确的方法。这也使租户可以共享产品，而不是添加重复项。由于一个租户的产品可能带有Product_id 1,2,3，另一个Product_id 1,2,3，因此您不能简单地合并表，因为您不能两次使用相同的ID-您需要唯一的主键值。
解决此问题的一种方法是编写一个程序(使用Java或另一种高级语言)，该程序将从租户数据库中读取所有数据到内存中对象中，然后将数据写入 Multi-Tenancy 模式中。对下一个租户数据库重复该过程，依此类推。这样，您将拥有ojit_code值1,2,3,4,5。一种快速而又肮脏的方法是在每个模式中的所有ID值上添加一个数字，例如1,000、2,000，依此类推，只要不动声色就可以了。
与数据库通信的代码
您将需要重写大多数数据库查询，以解决数据库现在是 Multi-Tenancy 的事实。这是一项艰巨的任务，尤其是考虑到引入一个使一个租户与另一个租户的数据混淆的错误的含义。但是，某些技术可以使此任务更容易。例如，Tenant View Filter可以大大减少所需的工作量。
租户数量限制
我从未见过关于限制 Multi-Tenancy 结构中的租户数量的建议。相反，strength of the multi-tenant approach是其可伸缩性。如今，您可以根据需要轻松地创建数据库服务器集群或使用基于云的解决方案来无缝添加更多硬件功能。
感兴趣的链接