Здравствуйте!

Прошу помощи у более опытных коллег.

Исходные данные:

Таблица данных продаж за пару лет


Таблица плана по продажам



В результирующей таблице необходимо объединить данные:
[date], [id_shop], [id_good], [sale] - факт продаж товара, [plan_sale] - установленный план продаж, [sale_prev_year] - продажи этого товара в прошлом году.

Проблема заключается в слишком долгом выполнении запросов: я join'ю к таблице Receipts таблицу Plan_sales по столбцам
[date], [id_shop], [id_good], снова join'ю таблицу receipts для получения выручки [sale] за прошлый год,
и при небольшом итоговом количестве строк (~5k) время выполнения доходит до 6-7 минут.



Кроме этих джойнов намечается ещё минимум три, справочная информация. Но уже на этом этапе процедура работает неудовлетворительно.

Подсказали, что в данной задаче необходимо использовать UNION ALL для оптимизации времени выполнения.
Непонятно, юнион чего с чем и, самое главное, для чего. Какие существуют подходы к решению подобных задач?

londinium,

да, обе таблицы имеют кластеризованный индекс по дате [date]

Неточно описал запрос, ниже скорректирован:

vikkiv,
vikkivсмотря что надо получить и в каком виде исходные данные,


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

vikkivесли в Plan_sales записи уникальны - то про Receipts вовсе не факт
(тогда сначала возможно нужна предварительная агрегация)
Да, там есть момент с агрегацией, но он выполнен шагом ранее и к нему вопросов нет.
Сейчас предполагается, что все значения уникальны.

vikkivтак-же неизвестно полный-ли набор в Plan_sales или в Receipts есть комбинации которых нет в Plan_sales
Набор неполный, на некоторые товары нет плана или "прошлого года"; в результирующей таблице будут NULL'ы по plan_sale и sale_prev_year (который spy.sale)

vikkivunion вероятно нужен для предварительного получения полного набора из обоих таблиц
(если результат нужен для идентификации проблем с любой стороны)
100% уникальность значений по ([date]-[id_shop]-[id_good]). Исходя из этого, я предполагаю, что нет разницы, какой юнион тут делать. Обычному Union нечего убирать из результата
vikkivнеплохо-бы по человечески алиасы поставить для каждого поля в select чтобы
не было проблем с выбором (из какого этапа join вытаскивать поле при их одинаковых названиях)
Добавил, сообщением ниже

Руководителем был забракован вариант внесения нескольких показателей в таблицу Plan_sales (я предполагал поместить туда и выручку, и план - и вот было бы готово уже два показателя: plan_sale и sale_prev_year, и джойна уже не два, а один). Руководителю я верю, значит, есть другой способ. Мне намекнули, что как-то надо использовать UNION (ALL).

Надеюсь, что смог добавить ясности..

invm,

alexeyvg,

по дате необходим кластерный индекс, т.к. дата есть основной параметр для любых выборок из таблицы.
Процедура на вход получает даты, все факты идут по дате. А самое главное, руководитель сказал "делать по дате!")

Насколько я сейчас понимаю, в процессе выполнения этой задачи и должна (по "стажёрскому" сценарию) возникать такая проблема.
Намёк заключался в том, что необходимо использовать UNION ALL. Единственное, что здесь в принципе возможно заюнионить, - это выборка нужных мне продаж по дате, нужных мне планов по дате, нужных мне продаж за прошлый год по дате, из двух таблиц с выполняющимся дважды запросом к одной из них. И как-то хитро провести юнион, чтобы в итоге это выглядело как результат join'a (или не как результат join'a? я сам с этим не разобрался и до сих пор не получается)