Просто Ваша статья о том как Вы "изобретали велосипед", то что Вы пытаетесь сделать это классическая проблема "Gaps and Islands", по ней можно найти кучу статей в сети и у нее есть классическое решение.
Слишком сложный запрос, все пишется в пару строк и без CTE:
SELECT volume, MIN(date) AS VT_BEG, MAX(date) AS VT_END
FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY date) - ROW_NUMBER() OVER (PARTITION BY volume ORDER BY date) as grp FROM #test) t
GROUP BY volume,grp ORDER BY VT_BEG
Простите вы заказчику продаете сотрудника или все же результат работы? Если стоимость работ для заказчика 1800, то не трудно посчитать что senior получив свои 250 баксов заработал для фирмы 1550. Плюс к этому в некоторых случаях заказчик готов платить больше за более быстрое выполнение работы, но не наоборот. Иначе выгоднее всего было нанимать людей которые вообще не умеют программировать время выполнения работы этими сотрудниками стремиться к бесконечности… PROFIT.
Последнее преобразование у меня не работает. Формирую тестовую таблицу:
SELECT * INTO Test FROM (Values (1,'2017-01-01'),(2,'2017-01-02'),(3,'2017-01-03'),(3,'2017-01-04'),(3,'2017-01-05'),(4,'2017-01-06'),(5,'2017-01-07'),(6,'2017-01-05')) AS t(Volume,Date)
После работы преобразования получаю:
data VT_BEG VT_END
3 2017-01-03 2017-01-05
Я не понимаю есть ГСЧ, есть его состояние, последовательность выигрышей проигрышей предопределена. Следовательно казино всегда останется «при своих». Максимум что может сделать злоумышленник играть когда «выгодно» и не играть когда «не выгодно», но если автомат находиться в состоянии «не выгодно», кто то должен его перевести в следующее состояние, будет это злоумышленник или другой игрок для казино нет никакой разницы, т.е максимум кого обманывает злоумышленник это другие игроки.
Да наверное это самая частая проблема и в то же время она же одна из самых нетривиальных, как убедить оптимизатор что он ошибся, а главное как заставить его сделать верные заключения. Т.е детекция данной проблемы это далеко еще не решение :(.
Наверное я необычный пользователь, но если мне сказать что в данных 100500 страниц, мне обязательно будет интересно что там на последней и что там на 50200 :)…
Тут скорее спрос рождает предложение, встретив трудности 99% школьников 5-7 классов разбегуться и не важно на сколько творческий подход будет у преподавателя. Смысл подобных кружков «программировать и создавать роботов легко и весело», только как в любой рекламе забывают упомянуть, что легко и весело будет только через несколько лет и только тем кто имеет багаж знаний и плоскую задницу. Большинство же будут просто нести деньги «преподавателям» и играть в «программистов».
Да кстати работают они в командах обычно не потому что это полезный опыт, а потому что конструкторов на всех не хватает, а брать деньги хочется как можно с большего кол-ва родителей.
Незнаю как у Вас, однако большинство подобных кружков сводиться к сборке по инструкции, по факту интересны первые 2-3 занятия, а потом начинается рутина и ребенок ничего не выносит. У меня сыну 13 и ничего лучше чем самообразование я так и не нашел.
Статья о том что в интернете можно найти кучу исследований «высосанных из пальца», а еще кучу неверных интерпретаций? Дочитал до конца и понял что потратил свое время в пустую, если вы еще не читали не делайте этого. :)
Возможно смысл раннего подъема не в том чтобы сделать что-либо раньше или позже. а в том чтобы максимально синхронизировать время бодрствования со светлым временем суток? Длительность светового дня приблизительно равно времени бодрствования, т.е. временем «чтобы сделать свой день успешным и полезным». Совпадение? Не думаю. :)
То что вы сделали в запросе называется old-style-join и является устаревшим со времен ввода стандарта SQL-92. Более 20 лет прошло может быть пора уже перейти на «новый» стандарт?
Есть несколько причин использовать «новый» стиль (если стандарта по вашему мнению не достаточно) могу привести еще несколько аргументов в пользу нового стиля. Во-первых разделения объединения и фильтраци в разные блоки. Во-вторых в случае если вы забыли указать условие объединения старый стиль приведет к расчету огроного объема данных и неверного результата (который может быть не так легко обнаружить), в то время как новый выдаст синтаксическую ошибку (http://blog.sqlauthority.com/2015/10/08/sql-server-why-should-you-not-to-use-old-style-join/). Можно продолжить гуглить и находить «за» и «против», а можно просто перейти на использование стандартов и выбросить дурное из головы. Ваш код могут читать люди которые родились после введения стандарта SQL-92 и ваш код будет выглядеть для них так, как будто его писали мамонты.
По-моему тот кто написал это не понял структуры таблиц и условий:
visitors легко упростить до
SELECT
sess.user_id,
sess.host_id,
sess.search_engine_id,
count(sess.id) as visitorquant
FROM session as sess
WHERE sess.search_engine_id > 0
AND (s.date = current_date OR sess.id IN (SELECT sh.id FROM session_hot as sh))
GROUP BY
sess.user_id,
sess.host_id,
sess.search_engine_id
dialogs можно заинлайнить тогда там уйдет куча группировок, а min(m.id) и последующий джойн заменить на TOP 1.
Так же бросается в глаза DATE_FORMAT(NOW(),"%Y-%m-%d 00:00:00") который вероятнее всего можно заменить на уже имеющийся CURRENT_DATE
Коррелирующие подзапросы часть языка не использовать их только потому, что оптимизатор может ошибиться мне кажется глупым. Запрос как и любая программа должен хорошо читаться, если для выразительности подзапрос выглядит лучше объединения, я буду использовать подзапрос. Когда же мы говорим о производительности, запрос сам по себе не может быть хорошим или плохим, всегда плохая производительность результат неудачного плана, а тот в свою очередь результат множества факторов из которых такой простой рефакторинг как замена subquery на join очень редко являются первопричиной (буду говорить только об оптимизаторе MSSQL поскольку плотно работал только с ним). Возможно для других движков имеют место подобные проблемы, тогда и говорить о подобных советах следует в контексте конкретного движка В общем случае только план запроса может быть необходимым и достаточным условием для оптимизации запроса.
На самом деле в MSSQL table variable и temp table хранятся в temp db и имеют очень мало отличий (речь не идет о использовании типов). Из главных отличий (в моей практике) это отсутствие статистики для table variable, в большенстве случае вы будете получать estimate в 1 запись, особенно это критично в сторед процедурах. Так же хочу заметить что записи в table variable не являются частью пользовательской транзакции. Наверное самый толковый пост по сравнению этих объектов (там же есть ссылка на Memory-Optimized Table Types) What's the difference between a temp table and table variable in SQL Server?
Оптимизатор может делать все это за вас, а вы пытаясь переписать код в пустуе потратите время. Оптимизатор зачастую отлично справится с COUNT и построит такой же план как и для EXISTS.
IF (SELECT count(*) FROM Users WHERE active = 1) > 0
Свободно преобразует подзапрос к джойну:
select top 100 CourseRegistrationID, (SELECT Email FROM Users WHERE UserID = cr.UserID) FROM CourseRegistrations cr
|--Top(TOP EXPRESSION:((100)))
|--Compute Scalar(DEFINE:([Expr1007]=[TestDB].[dbo].[Users].[Email]))
|--Nested Loops(Left Outer Join, OUTER REFERENCES:([cr].[UserID], [Expr1008]) WITH UNORDERED PREFETCH)
|--Index Scan(OBJECT:([TestDB].[dbo].[CourseRegistrations].[IX_CourseRegistrations_UserID] AS [cr]), ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([TestDB].[dbo].[Users].[PK_Users]), SEEK:([TestDB].[dbo].[Users].[UserID]=[TestDB].[dbo].[CourseRegistrations].[UserID] as [cr].[UserID]) ORDERED FORWARD)
Оптимизировать не имея статистики и не глядя в планы исполнения изначально является глупой затеей. Соберите статистику, проанализируйте план запроса и только после этого начинайте оптимизацию.
Если условия слишком сильно зависят от параметров, а параметры могут влиять на логику, в таком случае иногда выгоднее иметь не preparedstatement, а динамически сформированный запрос.
Просто Ваша статья о том как Вы "изобретали велосипед", то что Вы пытаетесь сделать это классическая проблема "Gaps and Islands", по ней можно найти кучу статей в сети и у нее есть классическое решение.
Слишком сложный запрос, все пишется в пару строк и без CTE:
SELECT * INTO Test FROM (Values (1,'2017-01-01'),(2,'2017-01-02'),(3,'2017-01-03'),(3,'2017-01-04'),(3,'2017-01-05'),(4,'2017-01-06'),(5,'2017-01-07'),(6,'2017-01-05')) AS t(Volume,Date)
После работы преобразования получаю:
data VT_BEG VT_END
3 2017-01-03 2017-01-05
Да кстати работают они в командах обычно не потому что это полезный опыт, а потому что конструкторов на всех не хватает, а брать деньги хочется как можно с большего кол-ва родителей.
Есть несколько причин использовать «новый» стиль (если стандарта по вашему мнению не достаточно) могу привести еще несколько аргументов в пользу нового стиля. Во-первых разделения объединения и фильтраци в разные блоки. Во-вторых в случае если вы забыли указать условие объединения старый стиль приведет к расчету огроного объема данных и неверного результата (который может быть не так легко обнаружить), в то время как новый выдаст синтаксическую ошибку (http://blog.sqlauthority.com/2015/10/08/sql-server-why-should-you-not-to-use-old-style-join/). Можно продолжить гуглить и находить «за» и «против», а можно просто перейти на использование стандартов и выбросить дурное из головы. Ваш код могут читать люди которые родились после введения стандарта SQL-92 и ваш код будет выглядеть для них так, как будто его писали мамонты.
visitors легко упростить до
SELECT
sess.user_id,
sess.host_id,
sess.search_engine_id,
count(sess.id) as visitorquant
FROM session as sess
WHERE sess.search_engine_id > 0
AND (s.date = current_date OR sess.id IN (SELECT sh.id FROM session_hot as sh))
GROUP BY
sess.user_id,
sess.host_id,
sess.search_engine_id
dialogs можно заинлайнить тогда там уйдет куча группировок, а min(m.id) и последующий джойн заменить на TOP 1.
Так же бросается в глаза DATE_FORMAT(NOW(),"%Y-%m-%d 00:00:00") который вероятнее всего можно заменить на уже имеющийся CURRENT_DATE
IF (SELECT count(*) FROM Users WHERE active = 1) > 0
|--Compute Scalar(DEFINE:([Expr1005]=CASE WHEN [Expr1006] THEN (1) ELSE (0) END))
|--Nested Loops(Left Semi Join, DEFINE:([Expr1006] = [PROBE VALUE]))
|--Constant Scan
|--Index Scan(OBJECT:([TestDB].[dbo].[Users].[IX_Users_Email]), WHERE:([TestDB].[dbo].[Users].[Active]=(1)))
IF EXISTS (SELECT 1 FROM Users WHERE active = 1)
|--Compute Scalar(DEFINE:([Expr1004]=CASE WHEN [Expr1005] THEN (1) ELSE (0) END))
|--Nested Loops(Left Semi Join, DEFINE:([Expr1005] = [PROBE VALUE]))
|--Constant Scan
|--Index Scan(OBJECT:([TestDB].[dbo].[Users].[IX_Users_Email]), WHERE:([TestDB].[dbo].[Users].[Active]=(1)))
Свободно преобразует подзапрос к джойну:
select top 100 CourseRegistrationID, (SELECT Email FROM Users WHERE UserID = cr.UserID) FROM CourseRegistrations cr
|--Top(TOP EXPRESSION:((100)))
|--Compute Scalar(DEFINE:([Expr1007]=[TestDB].[dbo].[Users].[Email]))
|--Nested Loops(Left Outer Join, OUTER REFERENCES:([cr].[UserID], [Expr1008]) WITH UNORDERED PREFETCH)
|--Index Scan(OBJECT:([TestDB].[dbo].[CourseRegistrations].[IX_CourseRegistrations_UserID] AS [cr]), ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([TestDB].[dbo].[Users].[PK_Users]), SEEK:([TestDB].[dbo].[Users].[UserID]=[TestDB].[dbo].[CourseRegistrations].[UserID] as [cr].[UserID]) ORDERED FORWARD)
Оптимизировать не имея статистики и не глядя в планы исполнения изначально является глупой затеей. Соберите статистику, проанализируйте план запроса и только после этого начинайте оптимизацию.
Если условия слишком сильно зависят от параметров, а параметры могут влиять на логику, в таком случае иногда выгоднее иметь не preparedstatement, а динамически сформированный запрос.