Как обрабатывать архивирование для сезонных значений базы данных на SQL Server - PullRequest
Новая
       28

Как обрабатывать архивирование для сезонных значений базы данных на SQL Server

0 голосов
/ 24 октября 2011

Я на SQL Server 2008 R2, и в настоящее время я разрабатываю структуру базы данных, которая содержит сезонные значения для некоторых продуктов.

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

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

Я могу автоматически выполнять автоматическое архивирование с заданиями SQL Server. Нет проблем там. Но я не уверен, как мне архивировать эти значения.

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

Пример:

Моя основная таблица называется ProductPrices, и там был первичный ключ определено для этой базы данных. Затем я создал еще одну таблицу с именем ProdutcPrices_archive. Я создал поле первичного ключа для этой таблицы а также те же столбцы, что и в таблице ProductPrices, за исключением ProdutPrices значение первичного ключа. Я не думаю, что это полезно заархивируйте это значение (я думаю, правильно?) .

Для внутреннего использования я рассмотрю возможность объединения двух табличных значений с UNION (Это правильный путь?) .

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

Любой совет будет оценен.

Ответы [ 2 ]

4 голосов
/ 24 октября 2011

Сначала я бы рассмотрел один из двух вариантов

  • Используйте разбиение , чтобы разделить одну таблицу на текущий рабочий набор и архивировать данные.
    Нет необходимости использовать архивную таблицу

  • Добавление столбцов validForm, ValidTo для реализации типа 2 SCD
    Затем добавьте индексированное представление для ValidTo IS NULL, чтобы получить текущий набор данных

У меня не было бы 2 отдельных таблиц, если бы все данные находились в режиме онлайн в одной базе данных.

Это приводит к третьему варианту: совершенно отдельная база данных со всеми данными. Только «текущие» данные остаются в живых. (как объясняет ответ @ Mike_Walsh)

Опция индексированного представления является самой простой и работает со стандартной версией (с подсказкой NOEXPAND)

1 голос
/ 24 октября 2011

ГБН предлагает несколько хороших подходов.Я думаю, что «правильный» долгосрочный ответ для вас - вариант t3rd.

Похоже, у вас есть два бизнес-варианта использования ваших данных -

1.) Онлайн-транзакция в реальном времениОбработка (OLTP).Это POS-транзакции, управление запасами, быстрое: «Как выглядели сегодня поступления, как обстоят дела с запасами, есть ли у нас какие-либо операционные проблемы?»вопросы и поддерживает бизнес в повседневной жизни.Здесь вам нужны данные, необходимые для выполнения операций, а также база данных, оптимизированная для обновлений / вставок / и т. Д.

2.) Вопросы аналитического типа / Отчетность.Это смотрит на число за месяц, число за год, средние значения.Это вопросы, которые вы задаете, поскольку они являются стратегическими и представляют полную картину вашей истории. Вы захотите увидеть, как в последние годы рождественские сезонные товары сравнивались с этими годами, может быть, даже сравнить эти цифры с сезонными товарами того же самогопериод 5 лет назад.Здесь вам нужна база данных, которая содержит намного больше данных, чем ваш OLTP.Вы хотите отбросить как можно меньше истории и хотите, чтобы база данных была в значительной степени оптимизирована для отчетов и ответов на вопросы.Вероятно, более денормализовано.Вам нужна возможность видеть вещи такими, какими они были в определенное время, поэтому здесь будут полезны SCD типа 2, упомянутые gbn.

Мне кажется, что вам нужно создать базу данных отчетов.Вы можете назвать это хранилищем данных, но этот термин пугает людей в наши дни.Не нужно быть страшным, если вы все спланируете правильно, вам не потребуется 6 лет и 6 миллионов долларов, чтобы заработать; -)

Это, безусловно, более долгосрочный ответ, но через пару летВы будете счастливы, что потратили время на его создание. Набор инструментов хранилища данных .

Хорошая книга для понимания концепции размерного моделирования и размышлений о хранилищах данных и их терминологии.
...