Моя компания хранит свои данные в базе данных Oracle.Он предлагает услуги нескольким другим компаниям, каждая из которых имеет тысячи клиентов, размещающих заказы.По историческим причинам все данные находятся в одной и той же схеме, и, например, все заказы находятся в одной таблице, скажем, ORDERS.
Теперь у нее проблемы с производительностью, и я хотел бы взять этовозможность управлять двумя целями:
- устранять проблемы с производительностью
- данных отдельных компаний по соображениям безопасности.
Сначала я решил использовать однусхема для каждой компании, которую мы обслуживаем :
- схема
A с таблицей с именем ORDERS, содержащей все заказы клиентов компании A - схема
B стаблица с именем ORDERS, содержащая все заказы клиентов компании B - и т. д....
но у нас есть еще одна проблема: у нас также есть несколько "суперкомпаний", которые также могут управлять данными для многих компаний.Например: «суперкомпания», управляющая заказами для компаний A и B.
При таком подходе есть ли способ управлять этими «суперкомпаниями»?Я подумал объявить другую схему (скажем, SUPERCOMPANY) с синонимом, который ссылается на объединение таблиц ORDERS из A и B, но:
- Есть ли проблемы с производительностью, имеющиесиноним ссылки на союз?Используются ли индексы таблиц?
- Как насчет INSERT?Как настроить таргетинг на соответствующую таблицу, если «суперкомпания» хочет добавить заказ для клиента, принадлежащего компании A?
Должны ли мы лучше использовать другое решение , как, если бы оно было ещебольшая база данных и схемы, ссылающиеся на соответствующий раздел большой таблицы ORDERS?(Я даже не знаю, возможно ли это)
- схема
DB, содержащая данные с огромной таблицей ORDERS, разбитой по компаниям. - схема
A, имеющаяссылка на синоним DB.ORDERS#partitionA - схема
B с ссылкой на синоним DB.ORDERS#partitionB - схема
SUPERCOMPANY с ссылкой на синоним DB.ORDERS или DB.ORDERS#partitionA and ORDERS#partitionB
Это звучит не очень хорошо для меня, потому что мы не должны нацеливаться непосредственно на разделы, не так ли?
У меня все еще есть надежда, и я уверен, что у Oracle есть решения для таких проблем, поскольку она является основным игроком дляреляционные базы данных.
Каков будет ваш подход?
Спасибо за чтение.