Как грамотно делать одни и те же операции над разными таблицами?

[OtherSide]

Суть задачи следующая:

Мой сервис обрабатывает биржевые данные. Есть огромная таблица сделок, есть несколько таблиц с агрегированными данными - таблица минутных свечек, дневных, агрегированные данные по объемам и т.д. всего штук 5-6. Плюс около дюжины хранимых процедур и функций.
Дело в том, что бирж обслуживается несколько. Когда добавил вторую - просто продублировал данные с префиксом. Третью - тоже.

Но сейчас стоит вопрос о подключении четвертой и пятой. Это не дело дублировать код опять. Еще не так сложно с таблицами, сколько с хранимыми процедурами. Какой тут может быть выход?

Можно ли например создать VIEW, который будет объединять таблицы в одну, а выбирать конкретную таблицу по индексу? На сколько это может тормозить?
Или для каждой биржи выделить отдельную базу. Но проблема в том, что код на клиенте работает только с одной, переписывать тоже неохота.
Или может в современных БД есть уже возможность инкапсуляции - объединения таблиц и хранимых процедур в единую структуру, от которых можно делать Instance?

[Alexandr]

Например, если говорить о сделках,
я бы сделал одну таблицу, в которой было бы поле id биржи, и разделил бы таблицу на разделы (partition) по ключу id, [диапазон дат, например, месяц или квартал].

Делать view для объединения таблиц - это был старый добрый метод, который существовал до того, как разделы (partition) стали полноценными сущностями

[Alexandr]

включение в ключ для раздела (partition key) дат, позволит вам по разному управлять архивными данными (сделки не добавляются в прошедшие периоды) и текущих данных, id - можно разнести каждую площадку (или группу площадок) в отдельные файловые группы, чтобы вы затыку по диску не получили

[OtherSide]

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

[mynameiszb]

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

Для партицированных таблиц начальный размер не так важен. Даже если у вас миллион записей или меньше, разбива по ключу позволит оптимизировать запросы.
Либо - если не хочется трогать существующую структуру, то надо подумать на тему Materialized View. Тоже вариант - агрегировать нужные данные в автоматическом режиме.

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

[OtherSide]

Хочу без сильного гемора сделать рефакторинг так, что бы была возможность легко подключать новые биржи. С нулевой просадкой по перформансу

[mynameiszb]

Хочу без сильного гемора сделать рефакторинг так, что бы была возможность легко подключать новые биржи. С нулевой просадкой по перформансу

Так в чем проблемы? Если база ваша, код ваш, править можно что угодно - так сделайте.

Я, как бывших db architect, вообще никаких проблем не вижу. Спроектировать структуру под себя - легко. Перегнать код с возможностью отката - ну, день-два работы на небольшой базе. Бэкапы сделать только заранее

Дальше - все упирается в конкретную реализацию базы. Для Оракла - это один комплект оптимальных технологий, для MS SQL - другой. Надо лишь определиться - делаете ли вы "кросплатформенную" табуретку, чтобы работало на всем, или затачиваете под фичи конкретной базы. Но в любом случае - задача очень простая. Надо лишь сначала разобраться с бизнес-логикой, потом расписать ее в реляционных преставлениях и затем уже можно итоговую схему раскидать по реальным таблицам + где что прилепить из багофич производителя.