Слабая связь между объектами в схеме оракула

Question

Я создаю информационную службу, которая управляет поставщиками. Поставщики используются нашей биллинговой системой, тендерной системой и системой продаж. Хотя 60% атрибутов поставщика являются уникальными для каждой системы, по-прежнему существует 40% атрибутов поставщика, которые являются общими для всех систем.

Моя цель - создать гибкую систему, чтобы изменение данных одной отдельной системы не влияло на другие системы. Например, если мне нужно отключить определенные таблицы для их обновления, это не должно повлиять на остальные системы, которым требуется информация о поставщике. Каков наилучший способ достижения этого? Должны ли все различные специфические для контекста атрибуты жить в одной схеме, но развернуты в разных табличных пространствах? Кроме того, чтение и обновление могут происходить чаще для одного набора атрибутов, чем для другого. Как мне логически представить их через одну модель, но развернуть их таким образом, чтобы они могли развиваться независимо?

Спасибо.

Answer 1

Звучит как очень сложный вопрос, на который здесь нелегко ответить.Но я могу вспомнить несколько хитростей, которые могут помочь вам с некоторыми из ваших проблем.Можно вносить огромные изменения в ваши данные и при этом поддерживать систему в оперативном режиме.

DBMS_REDEFINITION позволяет изменять структуру таблицы, пока другие люди все еще используют таблицу (хотя это выглядит очень сложно).

Разделение также позволяет вам изменять часть вашей таблицы, не затрагивая других пользователей.Например, вы можете усечь только один из разделов таблицы.Разделение также позволяет использовать разные физические структуры для одной и той же таблицы.Например, один раздел может использовать табличное пространство с небольшим размером блока (хорошо для записи), а другой раздел может использовать табличное пространство с большим размером блока (хорошо для чтения).

Answer 2

Во-первых, табличные пространства являются средством управления характеристиками хранения сегментов, они не помогут избежать влияния изменений.

Я рекомендую создавать отдельные дочерние таблицы для каждого набора атрибутов, каждый из которых имеетОграничение ссылочной целостности 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).