Разделение по годам против отдельных таблиц с именем Data_2011, Data_2010 и т. Д.

Question

Мы разрабатываем приложение SQL Server большого объема, которое включает обработку и создание отчетов по данным, которые ограничены в течение указанного года.

Запоминается использование разбиения по годам.

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

Моя интуиция говорит мне, что в этой ситуации дизайн разделов предназначен для обработки. Есть ли преимущества использования другого подхода?

Answer 1

С внутренней точки зрения методы в основном одинаковы.

За кулисами, когда вы создаете раздел на основе даты, движок SQL создает отдельные физические таблицы для каждого раздела, а затем выполняет то, что обычно является UNION, когда вы запрашиваете саму таблицу.

Если вы используете в своем запросе фильтр для секционированной таблицы, который соответствует вашему полю секционирования (скажем, DateField), то движок может перейти непосредственно к разделу, который вам нужен для данных. Если нет, то выполняется поиск каждой физической таблицы в логической таблице, необходимой для выполнения запроса.

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

По сути, выбор, который вам нужно сделать, - это хотите ли вы отвечать за все логические и угловые случаи, связанные с разбиением, или довериться разработчикам из Microsoft, которые десятилетиями занимались этим, сделать это для вас

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

Answer 2

Оба решения означают, что вам нужно выполнить некоторые операции с метаданными в БД. Вопрос в том, будете ли вы делать какие-то изменения / обновления в исторических данных? Я работал над аналогичным решением - но вместо того, чтобы год мы обрабатывали данные за полгода. В этом случае мы использовали разделение по дате - у нас есть полугодовое плавающее окно, в котором хранятся 2 года исторических данных + текущее полугодие (HTD) в 10 разделах (каждый раздел представляет отдельный квартал). Мы обновляли данные HTD каждый день и раз в неделю мы восстанавливали некоторые исторические данные. В этом случае мы использовали только несколько разделов (идентификатор раздела был определен в предложении where, ключом разделения был date_id, представляющий календарную дату в одном из наших измерений). Вся таблица имела около 250 миллионов строк. Каждое полугодие процесс корректирует разбиение, но то же самое вы будете делать с представлением. Используя этот подход, мы всегда можем выполнить обновление для всей таблицы (используя представление, вы должны будете протестировать сценарий обновления или запустить обновление для отдельных таблиц). У нас есть процедуры, которые могут обрезать / отключить указанный раздел таблицы, чтобы манипулирование было быстрым.

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

Answer 3

Я чувствую, что использование разбиения с ключом разделения на основе даты похоже на использование молотка для ввинчивания винта ... «Должно быть, именно поэтому они изобрели молоток» ... Разделение хорошо, когда вам нужны параллельные процессы для запускакак в витринах данных или вы разделяете на какой-то произвольный ключ, например, и столбец идентичности.В вашем случае бизнес-требование состоит в том, чтобы просто хранить многолетнюю историю.Чтобы использовать разбиение, команда приложения должна была бы создать подпрограмму, которая динамически генерирует ограничение разделения, которое является DDL и является ответственностью команды DBA.Представление с несколькими таблицами / объединениями обеспечивает намного более простое решение.