Доброго времени суток!
Обдумываю вот такую задачку, есть пара мест в довольно старой покупной системе с большим объемом накопленных данных.
Мне кажется, что там есть узкое место , и хочется его сгладить. Суть вот в чем (структуру максимально упростил):
-- есть таблица, например с некими заданиями/нарядами и т.д.
create table dbo.Document(doc_id int identity, date_doc datetime, order_id, cehid .....)
-- есть таблица с параметрами документа
create table dbo.Document_par(doc_id int , par_id int, value varchar(255) )
В отчетах основные поиски чаще всего выполняются или по дате документа (месяц, год квартал) и/или по заказам, подразделениям (order_id, cehid ), плохая новость в том, что date_doc - это просто дата ввода,
а дата отнесения документа хранится в параметре (с опр типом (par_id) в виде текста яля convert(varchar(10) , @dt, 104) ).
И поскольку искать надо именно по этому параметру, в отчетах есть куча ухищрений, чтобы делать это побыстрее. Но все равно, не быстро.
Мысли вот какие:
1. Приравнять Document.date_doc к значению параметра (или сделать отдельное поле). Хотябы в триггере на апдейт/инсерт таблицы параметров апдейтить дату в основной таблице.
Как минимум поиск по дате будет без преобразования типов и разных ухищрений.
2. Есть еще мысль о партиционировании таблицы, хотябы по году. Но тут вопрос не будет ли намного хуже при поиске по заказу или подразделению?
З.Ы. Т.е. с чем пытаюсь бороться. Параметры хранящиеся в преобразованном к Varchar виде по которым надо искать, и отсутствие в функционале механизмов некоей архивации что ли, когда неактуальный уже лет 13 объект лежит там же,
где и текущие, с которыми идет работа, ежедневно бэкапится. И соотношение активных к закрытым наверное 10 на 90 %.
Секционирование таблиц помогает исключительно в случаях изменения данных в этих талицах (нет есть конечно у оптимизатора функциональность когда он не лазит в лишние секции если запрос написан правильно, но это лишь малая часть в работе оптимизатора и врядли вам это поможет), у вас вроде как проблема с чтением этих данных, а это значит, копать вам надо в сторону индексов, они гораздо эффективнее борются со сканами таблиц:)
Плюс ничего не сказано про обьемы, секционирование оправдано бывает при объемах от сотен миллионов строк.
