Об архивных таблицах в одной или разных схемах

Question

Я работаю над Java-проектом с Oracle в качестве бэкэнда. У нас есть несколько таблиц - с большим объемом данных. Данные должны быть заархивированы через 6 месяцев в архивные таблицы.

У меня есть 2 варианта:

1. Основные таблицы и архивные таблицы должны быть в одной схеме.
2. Основные таблицы в одной схеме и архивные таблицы в другой схеме.

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

Какой из двух вариантов является лучшим дизайном? Каковы преимущества каждого?

Спасибо

Answer 1

Я только что сделал что-то подобное и для противостояния Ответ Джима на самом деле предпочитает другой маршрут схемы.

Есть несколько причин ...

Вы можете называть свои таблицы одним и тем же именем. Это полезно и легко увидеть, что происходит. Я назвал схему archive, поэтому все выборки были из archive.my_table. Если вы хотите объединить две таблицы вместе, например,

select * from prod.my_table 
 union 
select *  from archive.my_table

, который читается очень хорошо и однозначно.

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

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

Answer 2

Я работаю с похожим сценарием в двух разных продуктах. На мой взгляд, лучше всего держать их в одной и той же схеме, но для повышения производительности вы, вероятно, захотите, чтобы они были в разных табличных пространствах, с файлами данных для каждого табличного пространства на разных физических дисках (то есть с разными LUN в SAN для каждого табличного пространства). Это то, что мы делаем в нашем программном обеспечении для хранения данных; у нас есть таблицы, куда идут активные данные, и процедура истории перемещений, которая перемещает данные в таблицу HIST в конце дня.

Единственное реальное преимущество для других схем, кроме организации таблиц-аналогов, - это если вы хотите, чтобы схемы могли запускаться с разных серверов / экземпляров. Поскольку кажется, что вы хотели бы иметь возможность присоединяться к таблицам в определенных сценариях, вы не сможете иметь их в разных случаях (не без DBLink, и этого следует избегать). Так что нет особой пользы от другой схемы.