我正在构建一个管理供应商的信息服务。供应商由我们的计费系统、招标系统和销售系统使用。尽管供应商的60%的属性对于每个系统都是唯一的,但仍然有40%的供应商属性在系统之间共享。
我的目标是构建一个灵活的系统,这样对单个系统数据的更改不会影响其他系统。例如,如果我需要使某些表离线升级,这应该不会影响需要供应商信息的系统的其余部分。实现这一目标的最佳方法是什么?所有不同的特定于上下文的属性是否应该存在于一个模式中,但部署在不同的表空间中?此外,对于一组属性,读取和更新可能比另一组发生得更多。我应该如何通过一个模型在逻辑上表示它们,但又应该以这样一种方式部署它们,使它们可以独立发展?
谢谢。
发布于 2010-10-01 11:58:41
首先,表空间是一种控制段的存储特征的方法,它们不会帮助wrt避免更改带来的影响。
我建议您为每组属性创建单独的子表,每个子表与父表具有1:1的引用完整性约束。例如:
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)。
发布于 2010-10-01 12:33:22
这听起来是一个非常困难的问题,在这里不容易回答。但我可以想出一些小窍门,或许能帮助你解决一些问题。可以对您的数据进行巨大的更改,同时仍然保持系统在线。
DBMS_REDEFINITION允许您在其他人仍在使用表的情况下更改表结构(尽管它看起来非常复杂)。
分区还允许您在不影响其他用户的情况下更改表的一部分。例如,您可以只截断表的一个分区。分区还允许您对同一个表使用不同的物理结构。例如,一个分区可以使用块大小较小(适合写入)的表空间,而另一个分区可以使用块大小较大(适合读取)的表空间。
https://stackoverflow.com/questions/3833995
复制相似问题