SELECT INTO накладывает (раньше точно накладывал, может в последних версиях что-то изменилось) какие-то дополнительные блокировки на системные таблицы tempdb и большие запросы, если они долго вычисляются и выполняются, подвешивают в ожидание другие сессии.
про глобальные переменные п.68 как минимум в рамках T-SQL написано некорректно - нельзя объявить глобальных переменных, которые видны во всей сессии, в том числе внутри хранимых процедур.
Человек переносит архив статей с выключенного сайта sql.ru - часто своих переводов. Что в этом плохого? Вам жалко места на дисках хабра? Уровень знаний большей части разработчиков в части запросов к БД не превышает уровня SELECT * FROM - так что лишней информации тут не будет точно.
проблема в том что выработка именно этого гормона естественным образом снижается с возрастом - поэтому старики страдают бессонницей. И добыть его естественным путём при нашем образе жизни довольно сложно - всё равно придётся что-то пить(витамины, способствующие выработке этого гормона), ограничивать себя по питанию, соблюдать режим дня, световой режим - и всё равно его уровень с годами будет снижаться.
тут ещё может спасти OPTION(RECOMPILE) для отдельного запроса:
where ... and (@userid IS NULL or userid=@userid) and (@companyid IS NULL or companyid=@companyid) and (@deptid IS NULL or deptid=@deptid) OPTION(RECOMPILE)
когда значения переменных уже известны, то план меняется в лучшую сторону. хотя конечно платим временем за рекомпиляцию запроса.
Есть вариант перекидывать входящие переменные в локальные. Кстати в 2022й эту беду обещают победить и сделать хранение несколько планов для процедур и автоматически выбирать самый подходящий.
Мне кажется вы изобрели обычные материализованные представления, но где-то посередине всё сильно усложнили. Это же просто суммарные обороты по месяцам — а потом с этими оборотами можно делать что угодно — брать сумму за последние 12 месяцев, полгода, 3 года.
Не знаю как это реализовано в PostgreSQL, но в MSSQL и Oracle это нормально получается. С десятками миллионов проводок за год всё работает быстро и данные всегда гарантированно актуальные.
контролируется (есть чуть-чуть в flyway и всё), софт не способен работать с базами разных версий.
проблема синхронизации версий клиентской и серверной части всегда может быть и на любом уровне. Тут вопрос в организации тех.процесса — мы например клиентские модули храним в самой БД (динамические библиотеки) и загружаем их при подключении к ней. Там образом не может быть ситуации когда структура БД не синхронизована с клиентской частью, т.к. обновления охватывают сразу и клиентскую часть и серверную. Надо поработать со старой версией БД — берёшь её, а там и клиентские модули старой версии, своместимые с этой версией БД — всё работает. Конкретно в нашем случае нам этого достаточно, не претендую на универсальность.
Что касается темы — то если дальше развивать мысль, то нужно переносить часть бизнес-логики в уровень sql-сервера чтобы обеспечить максимальную производительность работы с большими объёмами данных. Буду с нетерпением ждать продолжения этой битвы ))
Сударыня, при всём уважении, вы непоследовательны:
Тут вторая особенность американского менталитета. Трампа никто не любит. Его считают полным придурком. Он несёт ересь и продолжает называть коронавирус «китайским вирусом», хотя китайцы категорически против.
Дальше народ побежал закупаться. Паника началась на неделю раньше, чем в России. Американцы рванули за туалетной бумагой и за продуктами питания, которые можно долго хранить.
Американцы очень законопослушны — если им сказали сидеть дома, они будут сидеть дома. Если им сказали карантин, значит карантин.
Что общего у людей из США и России. Паника и там, и там. СМИ раздули истерию. И люди не понимают, что происходит, начинают на всякий случай бояться. Только в США они начинают объединяться и «спасаться». А в России начинают разбегаться по домам и винить во всём власть, Путина, Трампа, Китай, всех.
Честно, не увидел разницы — люди везде одни и те же.
По последнему варианту — если использовать временную таблицу, первичный ключ, with(index(1)) и option(maxdop(1)) в update, то результат будет гораздо более стабилен и предсказуем.
Спасибо за цикл статей, очень познавательно. А вы могли бы в одной из своих будущих статей затронуть проблемы, которые могут встретиться при разработке на вашей платформе, ограничения, подводные камни? Что можно решить, обойти, а с чем придётся смириться? Мы же тут все понимаем что за всё приходится в какой-то момент платить — пишем на низком уровне, большие объёмы кода, который невозможно поддерживать, пишем на высоком уровне — ограничения платформы — и вам как никому должны быть известны все ваши слабые стороны.
Хороших результатов с оконными функциями я не добился на MSSQL, так что в данном случае особенно выкладывать думаю нечего и тратить на это время тоже — использование внутри функции расчёта таймфрейма для PARTITION BY несколько раз для каждой цены свечки — не самый хороший вариант:
DECLARE @STRIPE_ID int = 5
SELECT dbo.UT2DATESTR(UT), *
FROM (
SELECT STRIPE_ID = @STRIPE_ID,
STOCK_NAME,
dbo.TRUNC_UT(UT, @STRIPE_ID) AS UT,
AOPEN = FIRST_VALUE(APRICE) OVER (PARTITION BY dbo.TRUNC_UT(UT, @STRIPE_ID) ORDER BY UT),
ACLOSE = LAST_VALUE(APRICE) OVER (PARTITION BY dbo.TRUNC_UT(UT, @STRIPE_ID) ORDER BY UT RANGE BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING),
AMAX = MAX(APRICE) OVER (PARTITION BY dbo.TRUNC_UT(UT, @STRIPE_ID) ORDER BY UT RANGE BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING),
AMIN = MIN(APRICE) OVER (PARTITION BY dbo.TRUNC_UT(UT, @STRIPE_ID) ORDER BY UT RANGE BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING),
SORT = ROW_NUMBER() OVER (PARTITION BY dbo.TRUNC_UT(UT, @STRIPE_ID) ORDER BY UT ASC),
CNT = COUNT(*) OVER (PARTITION BY dbo.TRUNC_UT(UT, @STRIPE_ID)),
APRICE
FROM TRANSACTIONS_RAW) x
WHERE x.SORT = 1
Тут наверное нужно делать предварительный расчёт даты/времени в отдельных колонках таблицы для каждого таймфрейма и потом уже пользоваться ими в запросе.
Вобщем не самый оптимальный вариант.
Что касается скорости метода CALC — то я имел в виду ORACLE — он оказался чуть ли не на последнем месте — просто не хватило индексов в таблице?
Оконные функции использовать можно в подобных запросах — в этом случае можно не делать соединения таблицы самой с собой — иногда это выгодно. Вопрос производительности — это уже другой вопрос.
Скорее всего на практике вам не потребуются все данные, а только определённый объём за период и по определённому таймфрейму — это может привести совсем к другим показателям.
И очень странные результаты тестирования варианта CALC — как может вариант, где всё заранее посчитано и сложено в таблицу медленнее какого-то другого?
И ещё вот тут — min (1000000 * cast (UT as bigint) + ID) — маловато будет смещение для 11 млн записей. Да и не нужно такие сложности — достаточно просто min(ID) сделать.
Эта задача решается быстрее на Oracle, чем на MS SQL
Любая задача быстрее решается тем инструментом, которым лучше владеешь. Бегло посмотрел код на MSSQL — мне кажется там много где можно докрутить — типы курсоров, оконные функции, детерминирование функции TRUNC_UT и т.д. А вообще задача довольно простая — зачем так много вариантов перебирать и сравнивать сервера — что в итоге хотели получить?
Вы разницы между словами «продуктивный» и «прод», «продуктив» не замечаете? В первом случае — это неправильный перевод термина, а в вашем случае — это слэнг, перевод слова production. Давайте тогда введём в оборот все варианты перевода product — продуктовый, плодовый, результативный, а потом удивляться почему ракеты падают.
SELECT INTO накладывает (раньше точно накладывал, может в последних версиях что-то изменилось) какие-то дополнительные блокировки на системные таблицы tempdb и большие запросы, если они долго вычисляются и выполняются, подвешивают в ожидание другие сессии.
про глобальные переменные п.68 как минимум в рамках T-SQL написано некорректно - нельзя объявить глобальных переменных, которые видны во всей сессии, в том числе внутри хранимых процедур.
исправьте пожалуйста - Многозадачные представления (Materialized Views).
Человек переносит архив статей с выключенного сайта sql.ru - часто своих переводов. Что в этом плохого? Вам жалко места на дисках хабра? Уровень знаний большей части разработчиков в части запросов к БД не превышает уровня SELECT * FROM - так что лишней информации тут не будет точно.
проблема в том что выработка именно этого гормона естественным образом снижается с возрастом - поэтому старики страдают бессонницей. И добыть его естественным путём при нашем образе жизни довольно сложно - всё равно придётся что-то пить(витамины, способствующие выработке этого гормона), ограничивать себя по питанию, соблюдать режим дня, световой режим - и всё равно его уровень с годами будет снижаться.
Кажется у вас 3 ошибки в слове write - как-то режет глаз.
А что делать если потребуется новый тип товара? Или отобрать товары разных типов по какому-то одному атрибуту? Цвет скажем или высота?
тут ещё может спасти OPTION(RECOMPILE) для отдельного запроса:
where ...
and (@userid IS NULL or userid=@userid)
and (@companyid IS NULL or companyid=@companyid)
and (@deptid IS NULL or deptid=@deptid)
OPTION(RECOMPILE)
когда значения переменных уже известны, то план меняется в лучшую сторону. хотя конечно платим временем за рекомпиляцию запроса.
Есть вариант перекидывать входящие переменные в локальные. Кстати в 2022й эту беду обещают победить и сделать хранение несколько планов для процедур и автоматически выбирать самый подходящий.
Не знаю как это реализовано в PostgreSQL, но в MSSQL и Oracle это нормально получается. С десятками миллионов проводок за год всё работает быстро и данные всегда гарантированно актуальные.
проблема синхронизации версий клиентской и серверной части всегда может быть и на любом уровне. Тут вопрос в организации тех.процесса — мы например клиентские модули храним в самой БД (динамические библиотеки) и загружаем их при подключении к ней. Там образом не может быть ситуации когда структура БД не синхронизована с клиентской частью, т.к. обновления охватывают сразу и клиентскую часть и серверную. Надо поработать со старой версией БД — берёшь её, а там и клиентские модули старой версии, своместимые с этой версией БД — всё работает. Конкретно в нашем случае нам этого достаточно, не претендую на универсальность.
Что касается темы — то если дальше развивать мысль, то нужно переносить часть бизнес-логики в уровень sql-сервера чтобы обеспечить максимальную производительность работы с большими объёмами данных. Буду с нетерпением ждать продолжения этой битвы ))
Честно, не увидел разницы — люди везде одни и те же.
Тут наверное нужно делать предварительный расчёт даты/времени в отдельных колонках таблицы для каждого таймфрейма и потом уже пользоваться ими в запросе.
Вобщем не самый оптимальный вариант.
Что касается скорости метода CALC — то я имел в виду ORACLE — он оказался чуть ли не на последнем месте — просто не хватило индексов в таблице?
Скорее всего на практике вам не потребуются все данные, а только определённый объём за период и по определённому таймфрейму — это может привести совсем к другим показателям.
И очень странные результаты тестирования варианта CALC — как может вариант, где всё заранее посчитано и сложено в таблицу медленнее какого-то другого?
И ещё вот тут — min (1000000 * cast (UT as bigint) + ID) — маловато будет смещение для 11 млн записей. Да и не нужно такие сложности — достаточно просто min(ID) сделать.
Любая задача быстрее решается тем инструментом, которым лучше владеешь. Бегло посмотрел код на MSSQL — мне кажется там много где можно докрутить — типы курсоров, оконные функции, детерминирование функции TRUNC_UT и т.д. А вообще задача довольно простая — зачем так много вариантов перебирать и сравнивать сервера — что в итоге хотели получить?