Рекомендуемый способ запроса нескольких версионных таблиц

Question

У вас есть окно win 2003 с запущенным MSSQL 2005. Существует база данных, которая заполняется каждое утро новым / измененным SalesOrder, сделанным в предыдущий день. База данных имеет несколько таблиц: SalesOrder, SalesOrderItem, SalesOrderItemBom. Каждая из них имеет соответствующую таблицу Version (то есть SalesOrderVersion, SalesOrderItemVersion, SalesOrderItemBomVersion), которая имеет точно такие же поля, но с 2 дополнительными столбцами VersionStartDate, VersionEndDate. Не версионные таблицы содержат самые последние данные.

Также VersionStartDate является частью PK для таблиц версий, например, так: - SalesOrder имеет OrderID в качестве PK, а SalesOrderItem имеет VersionStartDate, OrderID в качестве PK.

Упрощенный пример работы таблицы версий:

SalesOrder

OrderID, сумма 1, 100 2, 200

SalesOrderVersion

VersionStartDate, OrderID, VersionEndDate, Amount 20090101 13:00:00, 1, 20090103 08:00:00, 50 20090103 08:00:00, 1, 99991231 00:00:00, 100 20090101 09:00:00, 2, 20090105 15:00:00, 300 20090105 15:00:00, 2, 99991231 00:00:00, 200

каждый раз, когда изменяется строка в SalesOrder, текущая строка VersionEndDate в SalesOrderVersion обновляется, и новая строка вставляется в SalesOrderVerion с VersionEndDate 99991231

Примечания. Если запись в SalesOrderItem была изменена, это не обязательно приведет к изменению «родительской» записи в SalesOrder

Было запрошено сделать отчет, показывающий тренд и ежедневный прирост продаж. Я думал о создании трех таблиц моментальных снимков для SalesOrder, SalesOrderItem, SalesOrderItemBom, которые собирают «последние данные» на текущий день и, таким образом, создают инкрементальные снимки для отображения тенденций. Помимо того, что требуется больше дискового пространства, есть ли у этого метода недостаток по сравнению с выполнением хранимой процедуры, которая соединяет таблицы версий, потому что это кажется длинным и дорогим запросом.

Есть мысли или рекомендации?

Answer 1

Здесь очень много "это зависит". Вот несколько идей для обсуждения.

Загружаются ли данные только утром? Это означало бы, что данные не меняются в течение дня, поэтому длинные дорогостоящие запросы не вызовут проблем с блокировкой или блокировкой. Эта база данных используется только для отчетности? Если нет - если данные обновляются в течение дня - могут потребоваться дополнительные избыточные копии данных для удовлетворения ваших требований.

Как часто будут запускаться новые отчеты? Будут ли они выполняться много, много раз за данный день или только один или два раза? Если к «агрегированным по времени» данным будет обращаться снова и снова, создание избыточной копии (моментального снимка) может быть целесообразным, но если отчеты будут запускаться один или два раза, а затем выводиться, я не знаю что я бы побеспокоил.

Насколько важна производительность? Должны ли отчеты генерироваться и завершаться в течение двух-трех секунд после того, как phb нажмет кнопку? (пауза) Нет, на самом деле, особенно если вы объясните им стоимость в долларах (дополнительное место на жестком диске, дополнительное место для резервного копирования, дополнительное время на подготовку, резервное копирование и восстановление, любые другие скрытые расходы, возникающие из-за раздувания данных). Если они могут подождать несколько минут для ежедневных отчетов, сделайте их дешевле. (У вас все еще есть первоначальные затраты на написание более сложного кода, но как только это будет сделано, это сделано. )

С другой стороны, добавление подпрограммы для генерации отчета за день после загрузки данных дня и сохранение только этого одного набора данных (или, возможно, набора данных за последнюю неделю, четыре недели и т. Д.) Имеет сильная привлекательность Если вы знаете, что они собираются запустить этот 5-минутный отчет, запустите его в AM, чтобы он был готов, когда они придут.

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