我正在建立一个管理供应商的信息服务。 我们的计费系统，招标系统和销售系统使用供应商。 尽管供应商的60％属性对于每个系统都是唯一的，但仍然有40％的供应商属性在系统之间共享。
我的目标是构建一个灵活的系统，以便更改为单个系统的数据，不应影响其他系统。例如，如果我需要使某些表脱机以进行升级，则不应影响其他需要供应商信息的系统。 实现这一目标的最佳方法是什么？是否所有不同的特定于上下文的属性都存在于一个模式中，但部署在不同的表空间中？ 此外，对于一组属性而言，读取和更新可能比另一组更多。我应该如何通过一个模型在逻辑上表示它们，但是以它们可以独立发展的方式部署它们？
谢谢。
答案 0 :(得分：1)
首先，表空间是控制段的存储特性的一种方法，它们无助于避免变更带来的影响。
我建议您为每组属性创建单独的子表，每个属性对父表具有1：1的参照完整性约束。 e.g。
SUPPLIERS (supplier_id PK, common attributes...)
SUPPLIER_BILLING_INFO (supplier_id PK, billing attributes...) + FK to SUPPLIERS
SUPPLIER_TENDER_INFO (supplier_id PK, tender attributes...) + FK to SUPPLIERS
SUPPLIER_SALES_INFO (supplier_id PK, sales attributes...) + FK to SUPPLIERS
显然他们需要住在一个实例中。无论是将它们放在一个模式中还是单独的模式中，都取决于您。
对一个系统的更改应该对其他系统没有影响，只要它们并非都引用所有表（即计费系统永远不应该访问SUPPLIER_TENDER_INFO）。
答案 1 :(得分：1)
这听起来像是一个非常困难的问题，在这里无法轻易回答。但我可以想到一些技巧可以帮助你解决一些问题。可以对您的数据进行大量更改，并使系统保持在线状态。
DBMS_REDEFINITION允许您更改表结构，而其他人仍在使用该表（虽然看起来非常复杂）。
分区还允许您更改表的一部分而不影响其他用户。例如，您只能截断表的一个分区。分区还允许您为同一个表使用不同的物理结构。例如，一个分区可以使用具有较小块大小的表空间（适合写入），而另一个分区可以使用具有较大块大小的表空间（适合读取）。