Есть система под Oracle с более 300 клиентами. В данный момент система не устраивает по некоторым требования и принято решение о переписывании всего с нуля.
Требуется разработать структуру БД для реализации под Oracle и Interbase (для установки на объекты с меньшим количеством пользователей и интенсивностью запросов).
Есть основная таблица, в которой много полей, основные - Идентификатор и Состояние.
Добавление записей в эту таблицу - 10 тыщ в день.
У каждой добавленной записи поле Состояние почти последовательно проходит значения от 1 до 10.
После достижения значения 10 запись становится архивной - поля не меняются.
Сегодняшняя реализация:
Все клиенты раз в 15 секунд делают выборку из этой таблицы с условием Состояние = Некоторой_константе, эта константа определяет тип приложения. Т.е. разные клиентские места выбирают записи с определенным состоянием и производят дальнейшую их обработку, меняя Состояние, тем самым передавая данную запись другим клиентам.
В сегодняшней реализации из-за большой загрузки сервера (доходит почти до 100%) сделано архивирование данных - объекты с Состоянием = 10 переносятся в другую таблицу. Через месяц еще в одну - для статистики. Все 3 таблицы имеют одинаковую структуру.
Обрабатывать 3 таблицы конечно не удобно, сделаны view`шки объединяющие все 3 таблицы и т.д.
Разработчиками были приняты следущие тезисы:
1. Алерты (события) - глючность, они не всегда работают. Поэтому выборка данных производится исключительно селектами.
2. Уменьшение количества записей в основной таблице до 1000 приводит к приемлимой нагрузке, доведение до 3-4 тысяч - к неприемлимой.
3. Для обеспечения приемлимой работоспособности необходимы архивные таблицы (они сделаны на других серверах).

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

ХОЧЕТСЯ И ЦЕЛОСТНОСТИ И БЫСТРОДЕЙСТВИЯ!
Часть базы является динамической - должна быть быстрой, часть архивной - десятки миллионов записей.

Есть понятие секционированные таблицы - но они тока в Оракле.
Можно сделать ключ на вьюшку, объединяющую основную и архивную таблицы - тоже тока в Оракле.

Конечно, варианты с алертами не отброшены, но в случае провала их использования структура меняться не должна.

Мой вариант: одна таблица с индексом по Состоянию. 2 вьюшки - одна заточена на Состояние = 10 (архив) другая наоборот Состояние <> 10 (рабочая). Вьюшки предназначены для большего разграничения доступа к таблице, что б каждая использовалась в своем контексте.
Думается, что select * from work_view where State = n не должен занимать много ресурсов?

Что посоветуете?

Ответы пишите в эту ветку: \r
/topic/75175