Рекомендации SQL Database Best Practices - Использование архивных таблиц?

Я не обученный администратор баз данных, но выполняю некоторые задачи SQL и задаю этот вопрос:

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

Зачем это нужно делать вместо того, чтобы использовать столбец для обозначения состояния строки, например логического для флага in/active?
В какой момент это улучшит производительность?
Каким будет наилучший шаблон для правильной структуризации, учитывая, что данные могут по-прежнему нуждаться в запросе (или объединены с текущими данными)?
Что еще можно сказать об этом?

Ответ 1

Понятие архивирования является физическим, а не логическим. Логически таблица архивов содержит ту же самую сущность и должна быть одной и той же таблицей.

Физические проблемы, как правило, прагматичны. Общепринятое понятие состоит в том, что "база данных тоже становится слишком большой (большой/медленной)). Архивирование записей упрощает выполнение таких действий, как:

Оптимизируйте структуру индекса по-разному. Архивные таблицы могут иметь больше индексов, не влияя на производительность вставки/обновления на рабочей таблице. Кроме того, индексы могут быть перестроены с полными страницами, в то время как рабочая таблица, как правило, хочет иметь страницы, которые на 50% полны и сбалансированы.
Оптимизируйте носители данных по-разному. Таблицу архива можно разместить на более медленных/менее дорогих дисках, которые могут иметь большую емкость.
Оптимизировать стратегии резервного копирования по-разному. Для рабочих таблиц могут потребоваться горячие резервные копии или отправка журналов, в то время как архивные таблицы могут использовать моментальные снимки.
Оптимизируйте репликацию по-разному, если вы ее используете. Если таблица архивов обновляется только один раз в день через ночную партию, вы можете использовать моментальный снимок, а не транзакционную репликацию.
Различные уровни доступа. Возможно, вам нужны разные уровни доступа к безопасности для таблицы архивов.
Заблокировать конфликт. Если рабочая таблица очень горячая, вы предпочитаете, чтобы ваши разработчики MIS обращались к таблице архива, где они с меньшей вероятностью останавливали ваши операции, когда они что-то запускали, и забывают указать грязную семантику чтения.

Лучшая практика не будет использовать архивные таблицы, а для перемещения данных из базы данных OLTP в базу данных MIS, хранилище данных или витрины данных с денормализованными данными. Но у некоторых организаций возникнут проблемы с обоснованием стоимости дополнительной системы БД (которые не являются дешевыми). Намного меньше препятствий для добавления дополнительной таблицы в существующую БД.

Ответ 2

Я говорю это часто, но...

Несколько таблиц одинаковой структуры почти никогда не имеют смысла.

Значок состояния - это гораздо лучшая идея. Существуют надлежащие способы повышения производительности (разбиение на разделы/индексирование) без денормализации данных или иного создания избыточности. 10 миллионов записей довольно малы в мире современных rdbms, поэтому то, что вы видите, является результатом плохого планирования или непонимания баз данных.