我的问题很简单：
我正在开发一个系统，它将安装在几家公司中。我不想在每个表中使用一个字段来将一个公司的数据分开到另一个公司，我想使用更具伸缩性的解决方案。
我的想法是建模单个数据库模式，并为我系统中的每个公司设置一个“实例”，从而备份单个数据库或基础模式，并通过修改我的每个模式传播更改基础架构。简而言之，它只有一个基础或物理模式及其许多数据实例，由唯一的模式名称引用。
这可能吗？这种技术叫做什么？ （我将首次使用这个概念）如何在IBM DB2上实现它？
答案 0 :(得分：1)
如果我理解正确，我认为不可能。我很确定这不实用。
想象一下，将该列的列和索引添加到基础架构中。在一家公司，他们没有大量数据，这种变化是相当微不足道的。但是，拥有数百万行的公司可能会发现自己突然没有磁盘空间。
DBA 可能通过将索引或表移动到不同的磁盘或不同的文件系统来管理该问题，但如果数据库是从基础架构“实例化”的话，则可能无法实现。 （取决于 instanced 的含义，它具有特定于DB2的含义以及更一般的OOP含义。）
您正在寻找的术语，我认为，是“多租户”。 （租户和客户在这里意味着相同的事情。）SO有一个“多租户”标签;我会为你添加它，你可以删除它，如果它不合适。 IBM的developerWorks库有一个introductory article on the various multi-tenant architectures。
多租户架构的范围从“无共享”（每个租户获得自己的数据库）到“共享所有内容”（所有租户在一个数据库中共享表，每行都有一列标识“拥有”的租户那一排）。
“无共享”和“共享所有内容”之间是“共享模式”（租户共享数据库;每个租户都有一个私有模式）。
最明显的区别在于自定义，灾难恢复和数据隔离。这些差异也推动了架构的选择。
“无共享”使定制变得容易;更改数据库不会影响任何其他租户。灾难恢复也很简单;您只需从备份还原整个数据库。可以在数据库级别应用权限以实现近乎完美的隔离。
“共享一切”使定制变得困难;每一个变化都会在一定程度上影响每个租户。灾难恢复也很困难;对于单一公司的灾难，您必须将一些行 - 只是单个公司“拥有”的行 - 还原到每个表。数据隔离也更难，因为您部署的每个视图和查询都必须正确地考虑租户标识符。忘记这一次，你可能会失业。