Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Делали тут небольшое сравнение СУБД и нарвались на вот какую проблему:

Запрос:

SELECT COUNT(*) FROM ShipmentDetail s1, ShipmentDetail s2 WHERE s1.sd=s2.sd AND s1.id <> s2.id


План запроса:
Rows	Executes  Stmt Text
1	1	  |--Compute Scalar(DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1008],0)))
1	1	       |--Hash Match(Aggregate, HASH:() DEFINE:([Expr1008]=COUNT(*)))
0	1	            |--Nested Loops(Inner Join, OUTER REFERENCES:([s1].[id], [s1].[sd], [Expr1007]) WITH UNORDERED PREFETCH)
10000001	1	                 |--Index Scan(OBJECT:([test].[dbo].[shipmentdetail].[shipmentdetail_sd] AS [s1]))
0	10000001	                 |--Index Seek(OBJECT:([test].[dbo].[shipmentdetail].[shipmentdetail_sd] AS [s2]), SEEK:([s2].[sd]=[test].[dbo].[shipmentdetail].[sd] as [s1].[sd]),  WHERE:([test].[dbo].[shipmentdetail].[id] as [s1].[id]<>[test].[dbo].[shipmentdetail].[id] as [s2].[id]) ORDERED FORWARD)


То есть MS SQL не догадывается бежать только по не NULL значениям. При этом если добавить явно IS NOT NULL все становится хорошо. Там может нужен какой-то специальный тип индекса?

И странно что Oracle отлично разруливает эту проблему.
12 авг 19, 10:57    [21946882]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Cammomile
Member

Откуда:
Сообщений: 1212
А почему вы задокументированное поведение называете проблемой? Тут нет никакой проблемы.
12 авг 19, 11:05    [21946901]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Cammomile
А почему вы задокументированное поведение называете проблемой? Тут нет никакой проблемы.


Ну так запрос выполняется 3 секунды. А у Oracle 30мс.
12 авг 19, 11:33    [21946942]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Konst_One
Member

Откуда:
Сообщений: 11429
oracle != mssql - запомните и дальше станет проще
12 авг 19, 11:45    [21946967]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Konst_One
oracle != mssql - запомните и дальше станет проще


Поверьте я это заметил. Я бы даже сказал это два антипода.

Причем, как человеку с навязчивым перфекционизмом, я очень благодарен Oracle. Потому как когда ты делаешь говно и тебя это напрягает, ты вспоминаешь что есть такая штука как Oracle и тебе становится гораздо легче.

Я когда тестировал три базы, и мне надо было что-то проверить на Oracle я понимал, что а) логику надо выключить, б) приготовиться долбаться с ним в раза 4 больше чем с остальными.
12 авг 19, 11:58    [21946989]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie,
в статье ребята не смогли в SQL, поэтому придумали какую-то свою приблуду и попытались написать, почему в SQL всё плохо.
Те же cross apply и instead of триггеры для вьюшек как-то упустили.
Может не знали - подтверждение что "не смогли в SQL". Если знали и не описали, ибо в статью слегка ломало - то что-то другое :)
12 авг 19, 12:04    [21946994]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Konst_One
Member

Откуда:
Сообщений: 11429
Курсоры, триггеры и развесистый pl/sql - это часто встречающийся подход в оракле, который ломается, когда вы хотите сделать так же на mssql. И, аналогично, обычные подходы из mssql часто не самые эффективные в оракле.
12 авг 19, 12:12    [21947006]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
andy st
Nitro_Junkie,
в статье ребята не смогли в SQL, поэтому придумали какую-то свою приблуду и попытались написать, почему в SQL всё плохо.
Те же cross apply и instead of триггеры для вьюшек как-то упустили.
Может не знали - подтверждение что "не смогли в SQL". Если знали и не описали, ибо в статью слегка ломало - то что-то другое :)


С CROSS APPLY дополнили статью. INSTEAD OF это не то в данном случае. Если вы сделаете триггер INSTEAD OF на balance, он не будет вызываться, когда скажем shipmentDetail поменялось, а там именно об этом речь шла.
12 авг 19, 12:12    [21947007]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Konst_One
Member

Откуда:
Сообщений: 11429
вы в той статье сами себя загнали в угол с такой архитектурой данных, которая не очень удобна для работы в mssql, а потом пытаетесь героически преодолеть ограничения.
12 авг 19, 12:13    [21947008]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Konst_One
Курсоры, триггеры и развесистый pl/sql - это часто встречающийся подход в оракле, который ломается, когда вы хотите сделать так же на mssql. И, аналогично, обычные подходы из mssql часто не самые эффективные в оракле.


Вот это странно, потому как триггеры в MS SQL имхо сделаны лучше чем в оракл. Во всяком случае там N+1 проблему победили. И многие ораклоиды поэтому мне говорили, что стараются избегать триггеров.
12 авг 19, 12:42    [21947045]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Konst_One
вы в той статье сами себя загнали в угол с такой архитектурой данных, которая не очень удобна для работы в mssql, а потом пытаетесь героически преодолеть ограничения.


А что там такого особенного в архитектуре. Там же просто документы/ остатки и т.п. Или вы что-то другое имеете ввиду?
12 авг 19, 12:44    [21947051]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Konst_One
Member

Откуда:
Сообщений: 11429
имелось ввиду как вы эти данные храните (стуктуру таблиц и их взаимосвязь)
12 авг 19, 12:46    [21947052]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie
andy st
Nitro_Junkie,
в статье ребята не смогли в SQL, поэтому придумали какую-то свою приблуду и попытались написать, почему в SQL всё плохо.
Те же cross apply и instead of триггеры для вьюшек как-то упустили.
Может не знали - подтверждение что "не смогли в SQL". Если знали и не описали, ибо в статью слегка ломало - то что-то другое :)


С CROSS APPLY дополнили статью. INSTEAD OF это не то в данном случае. Если вы сделаете триггер INSTEAD OF на balance, он не будет вызываться, когда скажем shipmentDetail поменялось, а там именно об этом речь шла.

ммм...
а давайте придумаем еще еще какие-нибудь свои правила и будем радоваться, что ни одна субд их не поддерживает.
12 авг 19, 13:12    [21947086]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Konst_One
имелось ввиду как вы эти данные храните (стуктуру таблиц и их взаимосвязь)


А как если не секрет по вашему нужно было структуру таблиц в данном случае организовывать?
12 авг 19, 14:08    [21947165]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
andy st
Nitro_Junkie
пропущено...


С CROSS APPLY дополнили статью. INSTEAD OF это не то в данном случае. Если вы сделаете триггер INSTEAD OF на balance, он не будет вызываться, когда скажем shipmentDetail поменялось, а там именно об этом речь шла.

ммм...
а давайте придумаем еще еще какие-нибудь свои правила и будем радоваться, что ни одна субд их не поддерживает.


Что значит придумывать правила? Допустим вам надо логировать ситуации, когда количество остатка стало меньше 0. Вроде элементарная задача, как ее при помощи INSTEAD OF триггера реализовать?
12 авг 19, 14:10    [21947171]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie
andy st
пропущено...

ммм...
а давайте придумаем еще еще какие-нибудь свои правила и будем радоваться, что ни одна субд их не поддерживает.


Что значит придумывать правила? Допустим вам надо логировать ситуации, когда количество остатка стало меньше 0. Вроде элементарная задача, как ее при помощи INSTEAD OF триггера реализовать?

а делать это на этапе добавления записи, которая может привести к остатку < 0, не?
или подразумевается, что кто-то может править содержимое вьюхи в плане изменения остатка? типа чёта мало тут, давай сотку накинем... тогда ребята правильно путём идут бизнес делать.
12 авг 19, 14:22    [21947184]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
andy st
Nitro_Junkie
пропущено...


Что значит придумывать правила? Допустим вам надо логировать ситуации, когда количество остатка стало меньше 0. Вроде элементарная задача, как ее при помощи INSTEAD OF триггера реализовать?

а делать это на этапе добавления записи, которая может привести к остатку < 0, не?
или подразумевается, что кто-то может править содержимое вьюхи в плане изменения остатка? типа чёта мало тут, давай сотку накинем... тогда ребята правильно путём идут бизнес делать.


Какой записи? Допустим у вас остаток расчитывается, как-то хитро.

Кто-то делает какое-то изменение UPDATE shipmentDetail SET product=54 WHERE id=123

Это для старого товара уменьшит остаток, для нового увеличит. То есть остаток может стать меньше 0, это хочется залогировать (для склада товара), вместе скажем с человеком и изменением которые привели к этому.

Если бы можно было сделать триггер на представление balance все делалось бы одной строчкой. А так вариантов которые приведут к тому что останет меньше 0 сотни. Куда что вставлять?
12 авг 19, 14:50    [21947210]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Konst_One
Member

Откуда:
Сообщений: 11429
остаток не должен расчитываться, он должен записываться
12 авг 19, 14:54    [21947215]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
invm
Member

Откуда: Москва
Сообщений: 8717
Nitro_Junkie
Если бы можно было сделать триггер на представление balance все делалось бы одной строчкой.
Ну так делайте. Или что-то мешает?
12 авг 19, 15:53    [21947296]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6639
Nitro_Junkie,

SELECT COUNT(*) FROM ShipmentDetail s1, ShipmentDetail s2 WHERE s1.sd=s2.sd AND s1.id <> s2.id


Вы чего-то не договариваете. У меня план запроса на таблице с индексом по nullable колонке очень простой - constant scan. Скорее всего,выбран тривиальный план.

Версия сервера какая, интересно?
12 авг 19, 16:28    [21947348]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Konst_One
остаток не должен расчитываться, он должен записываться


Ну для начала определяется как должен рассчитываться, а как записываться это уже следствие.
12 авг 19, 17:27    [21947412]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
invm
Nitro_Junkie
Если бы можно было сделать триггер на представление balance все делалось бы одной строчкой.
Ну так делайте. Или что-то мешает?

MS SQL не дает триггеры на представления делать.
12 авг 19, 17:28    [21947414]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Konst_One
Member

Откуда:
Сообщений: 11429
Nitro_Junkie
Konst_One
остаток не должен расчитываться, он должен записываться


Ну для начала определяется как должен рассчитываться, а как записываться это уже следствие.



не надо для этого делать представления, программа должна уже расчитанный остаток зхаписывать в отдельную таблицу
12 авг 19, 17:31    [21947417]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1011
Nitro_Junkie
invm
пропущено...
Ну так делайте. Или что-то мешает?

MS SQL не дает триггеры на представления делать.

А пацаны то не знали...

https://docs.microsoft.com/ru-ru/sql/t-sql/statements/create-trigger-transact-sql?view=sql-server-2017

CREATE [ OR ALTER ] TRIGGER [ schema_name . ]trigger_name
ON { table | view }
12 авг 19, 17:31    [21947418]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Владислав Колосов
Nitro_Junkie,

SELECT COUNT(*) FROM ShipmentDetail s1, ShipmentDetail s2 WHERE s1.sd=s2.sd AND s1.id <> s2.id


Вы чего-то не договариваете. У меня план запроса на таблице с индексом по nullable колонке очень простой - constant scan. Скорее всего,выбран тривиальный план.

Версия сервера какая, интересно?


Да в том то и проблема, что выбирается тривиальный план.

SQL Server (15.0.1700.37) это 2019 preview как я понимаю. Но на эту проблему мне на всех серверах жаловались.
12 авг 19, 17:31    [21947419]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
invm
Member

Откуда: Москва
Сообщений: 8717
Nitro_Junkie
MS SQL не дает триггеры на представления делать.
Вы просто не в курсе, что для представлений допустимы instead of триггеры.
Nitro_Junkie
Да в том то и проблема, что выбирается тривиальный план.
Проблема в том, что такой оптимизации в MSSQL нету. Тривиальность плана ни при чем.
12 авг 19, 18:21    [21947458]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie
andy st
пропущено...

а делать это на этапе добавления записи, которая может привести к остатку < 0, не?
или подразумевается, что кто-то может править содержимое вьюхи в плане изменения остатка? типа чёта мало тут, давай сотку накинем... тогда ребята правильно путём идут бизнес делать.


Какой записи? Допустим у вас остаток расчитывается, как-то хитро.

Кто-то делает какое-то изменение UPDATE shipmentDetail SET product=54 WHERE id=123

Это для старого товара уменьшит остаток, для нового увеличит. То есть остаток может стать меньше 0, это хочется залогировать (для склада товара), вместе скажем с человеком и изменением которые привели к этому.

Если бы можно было сделать триггер на представление balance все делалось бы одной строчкой. А так вариантов которые приведут к тому что останет меньше 0 сотни. Куда что вставлять?

т.е. вариант, когда это будет делать триггер на shipmentDetail даже не рассматривается?
и разве в balance есть пользователь и вообще какие-то данные, которые могли бы идентифицировать измененную запись? там обезличенные аггрегаты.
Или подразумевается, что триггер в одну строку на view сможет из изменению 1 значения идентифицировать строку, которая привела к этому? Ну напишите, что ли, новый стандарт ХЗQL по этому поводу, опишите поведение. В MSSQL 2025 это будет реализовано, как пить дать
12 авг 19, 19:16    [21947490]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Konst_One
Nitro_Junkie
пропущено...


Ну для начала определяется как должен рассчитываться, а как записываться это уже следствие.



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


Представление определяет что мы хотим получить. Как это представление должно обновляться уже задача SQL сервера. То что они этого не умеют делать, ну значит руки не из того места растут. В том же lsFusion так можно делать.
12 авг 19, 21:54    [21947552]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Minamoto
А пацаны то не знали...

invm
Вы просто не в курсе, что для представлений допустимы instead of триггеры.

Издеваетесь? Я же сверху писал, что триггер INSTEADOF на balance вам никак не поможет, в задаче выполнения действий, когда остаток станет меньше 0.
12 авг 19, 21:56    [21947554]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
andy st
Nitro_Junkie
пропущено...


Какой записи? Допустим у вас остаток расчитывается, как-то хитро.

Кто-то делает какое-то изменение UPDATE shipmentDetail SET product=54 WHERE id=123

Это для старого товара уменьшит остаток, для нового увеличит. То есть остаток может стать меньше 0, это хочется залогировать (для склада товара), вместе скажем с человеком и изменением которые привели к этому.

Если бы можно было сделать триггер на представление balance все делалось бы одной строчкой. А так вариантов которые приведут к тому что останет меньше 0 сотни. Куда что вставлять?

т.е. вариант, когда это будет делать триггер на shipmentDetail даже не рассматривается?
и разве в balance есть пользователь и вообще какие-то данные, которые могли бы идентифицировать измененную запись? там обезличенные аггрегаты.
Или подразумевается, что триггер в одну строку на view сможет из изменению 1 значения идентифицировать строку, которая привела к этому? Ну напишите, что ли, новый стандарт ХЗQL по этому поводу, опишите поведение. В MSSQL 2025 это будет реализовано, как пить дать


Вы себе представляете, сколько и каких триггеров там должно быть, если balance хоть сколько нибудь сложный. Ну например с внутренними перемещениями.

Ну в задаче было не про строку, а хотя бы пользователя.

А вообще мы это все реализовали в lsFusion.
12 авг 19, 21:59    [21947558]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
PizzaPizza
Member

Откуда:
Сообщений: 276
Всегда удивляют изобретатели SQL

Вам там на хабре уже наобъясняли подробно, что вы занимаетесь очередным нишевым продуктом, но по какой то причине, называете это убийцей SQL

Эти скучные базы данных делают простые три вещи: читают данные с диска, читают данные из памяти и обрабатывают их с помощью процессора. Это физика, тут все давно оптимизировано по самое небалуйся и придумать ничего нельзя никак совсем. Не получите вы данные с диска не прочитав их сначала... Дальше вопрос реализации хранения, чтения и обработки. У вас есть свои (лучшие) алгоритмы на физические операторы?

Зато у вас в языке абстракция на абстракции, материализации и индексы, которые по волшебству хранят сразу все в святом духе и не требуют сканов, сиков и никаких ограничений конечно. Прям отмена закона сохранения энергии: и данные получаем посчитанные и память не тратим и производительность не страдает. Действительно, зачем тогда архитектура, триггеры и логика, когда все святым духом сразу выбирается и считается само. И все за счет синтаксиса, между прочим!

Не, конечно долго можно расписывать как одна абстракция реализована лучше/хуже другой в том или ином продукте, но не бывает волшебной таблетки, когда вопрос в железе, в физике. А писать можно хоть на ассемблере.
13 авг 19, 02:25    [21947613]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie
andy st
т.е. вариант, когда это будет делать триггер на shipmentDetail даже не рассматривается?
и разве в balance есть пользователь и вообще какие-то данные, которые могли бы идентифицировать измененную запись? там обезличенные аггрегаты.
Или подразумевается, что триггер в одну строку на view сможет из изменению 1 значения идентифицировать строку, которая привела к этому? Ну напишите, что ли, новый стандарт ХЗQL по этому поводу, опишите поведение. В MSSQL 2025 это будет реализовано, как пить дать

Вы себе представляете, сколько и каких триггеров там должно быть, если balance хоть сколько нибудь сложный. Ну например с внутренними перемещениями.
Ну в задаче было не про строку, а хотя бы пользователя.
А вообще мы это все реализовали в lsFusion.

Т.е. в lsFusion в balance по обезличенной агрегированной строке, число в которой считаются по алгоритму "balance хоть сколько нибудь сложный" из зависит от 100500 пользователей триггером можно определить конкретного пользователя? ну всё! круто! sql-базы в очередной раз будут похоронены и сотни тысяч sql-программистов будут выкинуты на улицу.
p.s. уже лет так 25, как продолжаются похороны реляционных БД и того же Delphi. В процессе похорон было закидано еловыми ветками несколько трупов хоронящих. Но появляются новые члены процессии и процесс продолжается.
13 авг 19, 05:53    [21947634]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
PizzaPizza
Всегда удивляют изобретатели SQL

Вам там на хабре уже наобъясняли подробно, что вы занимаетесь очередным нишевым продуктом, но по какой то причине, называете это убийцей SQL


Область применения lsFusion вполне конкретная - разработка информационным систем. То есть почти полностью совпадает с SQL. Так что в этом смысле и SQL - очередной нишевой продукт.

И на хабре людей и мнений огромное число. SQL девелоперы считают одно. 1с - другое. .Net-третье, Web - четвертое. Web разработчики нас вообще тянут революцию в веб делать прикручивая React.

PizzaPizza
Эти скучные базы данных делают простые три вещи: читают данные с диска, читают данные из памяти и обрабатывают их с помощью процессора. Это физика, тут все давно оптимизировано по самое небалуйся и придумать ничего нельзя никак совсем. Не получите вы данные с диска не прочитав их сначала... Дальше вопрос реализации хранения, чтения и обработки. У вас есть свои (лучшие) алгоритмы на физические операторы?


Физически компьютеры просто читают данные из памяти, записывают их в регистры процессора, а потом выполняют команды процессора. А эти гуглы и jetbrains'ы со своими go и kotlin возятся. У них есть свои физические операторы работы с процессором?

PizzaPizza
Зато у вас в языке абстракция на абстракции, материализации и индексы, которые по волшебству хранят сразу все в святом духе и не требуют сканов, сиков и никаких ограничений конечно. Прям отмена закона сохранения энергии: и данные получаем посчитанные и память не тратим и производительность не страдает. Действительно, зачем тогда архитектура, триггеры и логика, когда все святым духом сразу выбирается и считается само. И все за счет синтаксиса, между прочим!

Требуют и сканы и сики , но кроме этого есть еще оптимизаторы в общем случае, прозрачные материализации, события и ограничения на вычисляемые данные и кучу чего еще что не умеют SQL сервера. И не по волшебству, а в результате огромного количества человека часов. И синтаксис тут совсем не причем. Синтаксис в данном случае это 1%, его можно изменить как угодно, функционал не изменится.

PizzaPizza
А писать можно хоть на ассемблере.

Но почему-то не пишут. А знаете почему? Потому что время разработчика в современном мире очень дорогое.
13 авг 19, 09:41    [21947710]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
andy st
Nitro_Junkie
пропущено...

Вы себе представляете, сколько и каких триггеров там должно быть, если balance хоть сколько нибудь сложный. Ну например с внутренними перемещениями.
Ну в задаче было не про строку, а хотя бы пользователя.
А вообще мы это все реализовали в lsFusion.

Т.е. в lsFusion в balance по обезличенной агрегированной строке, число в которой считаются по алгоритму "balance хоть сколько нибудь сложный" из зависит от 100500 пользователей триггером можно определить конкретного пользователя? ну всё! круто! sql-базы в очередной раз будут похоронены и сотни тысяч sql-программистов будут выкинуты на улицу.
p.s. уже лет так 25, как продолжаются похороны реляционных БД и того же Delphi. В процессе похорон было закидано еловыми ветками несколько трупов хоронящих. Но появляются новые члены процессии и процесс продолжается.


В lsFusion можно любой показатель указать MATERIALIZED и он будет храниться в таблице и автоматически эффективно транзакционно обновляться на любом объеме данных. Назовете еще один труп, который хотя бы это умеет делать. Ну или треть из этого.
13 авг 19, 09:43    [21947712]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1011
Nitro_Junkie
Minamoto
А пацаны то не знали...

invm
Вы просто не в курсе, что для представлений допустимы instead of триггеры.

Издеваетесь? Я же сверху писал, что триггер INSTEADOF на balance вам никак не поможет, в задаче выполнения действий, когда остаток станет меньше 0.

Нет. Вы писали:
Nitro_Junkie
MS SQL не дает триггеры на представления делать.
13 авг 19, 10:20    [21947745]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie
andy st
пропущено...
Т.е. в lsFusion в balance по обезличенной агрегированной строке, число в которой считаются по алгоритму "balance хоть сколько нибудь сложный" из зависит от 100500 пользователей триггером можно определить конкретного пользователя? ну всё! круто! sql-базы в очередной раз будут похоронены и сотни тысяч sql-программистов будут выкинуты на улицу.
p.s. уже лет так 25, как продолжаются похороны реляционных БД и того же Delphi. В процессе похорон было закидано еловыми ветками несколько трупов хоронящих. Но появляются новые члены процессии и процесс продолжается.


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

а пользователя то в разрисованной выше задаче определит или как?
select COUNT_BIG(*) from [values]
--------------------
43939522237

(затронута одна строка)
добавка данные ~100к строк в минуту
этот показатель можно тож заматериализовать?
и будет работать?
пошел качать...

Ну и что-то с таким функционалом должно когда-нибудь стать первым :)
13 авг 19, 10:53    [21947786]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie,
еще на заметку, в SQL Server есть такая фишка
13 авг 19, 10:58    [21947798]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie
...Web разработчики нас вообще тянут революцию в веб делать прикручивая React...

из фраз заказчика:
автор
.. а Вы не могли бы сделать рабочее место в виде обычной программы, а не через интернет. У нас на рабочих планшетах хром сильно тормозит...
13 авг 19, 11:24    [21947840]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Minamoto
Nitro_Junkie
пропущено...

пропущено...

Издеваетесь? Я же сверху писал, что триггер INSTEADOF на balance вам никак не поможет, в задаче выполнения действий, когда остаток станет меньше 0.

Нет. Вы писали:
Nitro_Junkie
MS SQL не дает триггеры на представления делать.


INSTEAD OF это по сути не триггеры. Они просто называются тем же словом.
13 авг 19, 11:36    [21947856]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
andy st
Nitro_Junkie
пропущено...


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

а пользователя то в разрисованной выше задаче определит или как?
select COUNT_BIG(*) from [values]
--------------------
43939522237

(затронута одна строка)
добавка данные ~100к строк в минуту
этот показатель можно тож заматериализовать?
и будет работать?
пошел качать...

Ну и что-то с таким функционалом должно когда-нибудь стать первым :)


У вас UPDATE CONFLICT'ов будет много. Но как-то работать будет. Так что лучше x= SELECT COUNT_BIG(*) from [values] GROUP BY [выражение, где разновидностей хотя бы 1000]. А потом представление SELECT SUM() from x оставьте нематериализованным и используйте его.
13 авг 19, 11:41    [21947864]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
andy st
Nitro_Junkie,
еще на заметку, в SQL Server есть такая фишка


И к чему эта фишка. Особенно, когда неизвестно разреженная колонка будет или нет. Точнее она может быть разреженной, а потом быстро стать не разреженной. Очень удобный функционал.
13 авг 19, 11:42    [21947866]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
andy st
Member

Откуда:
Сообщений: 741
Nitro_Junkie
andy st
Nitro_Junkie,
еще на заметку, в SQL Server есть такая фишка

И к чему эта фишка. Особенно, когда неизвестно разреженная колонка будет или нет. Точнее она может быть разреженной, а потом быстро стать не разреженной. Очень удобный функционал.

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

p.s. про того ^^ пользователя из balance уже и не спрашиваю...
13 авг 19, 11:54    [21947884]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
andy st
Nitro_Junkie
пропущено...

И к чему эта фишка. Особенно, когда неизвестно разреженная колонка будет или нет. Точнее она может быть разреженной, а потом быстро стать не разреженной. Очень удобный функционал.

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

p.s. про того ^^ пользователя из balance уже и не спрашиваю...


Поэтому в идеале как можно больше должен делать сам сервер. В том числе в идеале добавлять материализации и определять расположение в таблицах. Хотя до этого даже мы не дошли пока. Но хотя бы сделали эти механизмы прозрачными.
13 авг 19, 12:00    [21947897]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Megabyte
Member

Откуда: ближайшее заМКАДье
Сообщений: 4813
Ну что, когда ждать смерти SQL? Есть примерные сроки?
13 авг 19, 17:36    [21948436]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Megabyte
Ну что, когда ждать смерти SQL? Есть примерные сроки?


На следующей неделе я думаю :)

Хотя смерть в данном контексте неправильное слово. Мы же не говорим о смерте машинных кодов. Просто есть абстракции компилируемые в этот машинный код. А сами машинные коды - живее всех живых.
13 авг 19, 17:40    [21948441]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2281
andy st
Nitro_Junkie,
в статье ребята не смогли в SQL, поэтому придумали какую-то свою приблуду и попытались написать, почему в SQL всё плохо.
Те же cross apply и instead of триггеры для вьюшек как-то упустили.
Может не знали - подтверждение что "не смогли в SQL". Если знали и не описали, ибо в статью слегка ломало - то что-то другое :)
Причем приблуда все равно использует существующие БД которуые так опускают в статье.
А вообще если бы статья не была бы чистой воды рекламой я бы сказал что её писали идиоты. А так, в принципе понятно зачем и почему так написано.
13 авг 19, 22:26    [21948660]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2281
andy st
Nitro_Junkie,
в статье ребята не смогли в SQL, поэтому придумали какую-то свою приблуду и попытались написать, почему в SQL всё плохо.
Те же cross apply и instead of триггеры для вьюшек как-то упустили.
Может не знали - подтверждение что "не смогли в SQL". Если знали и не описали, ибо в статью слегка ломало - то что-то другое :)
Причем приблуда все равно использует существующие БД которуые так опускают в статье.
А вообще если бы статья не была бы чистой воды рекламой я бы сказал что её писали идиоты. А так, в принципе понятно зачем и почему так написано.
13 авг 19, 22:28    [21948663]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Mind
andy st
Nitro_Junkie,
в статье ребята не смогли в SQL, поэтому придумали какую-то свою приблуду и попытались написать, почему в SQL всё плохо.
Те же cross apply и instead of триггеры для вьюшек как-то упустили.
Может не знали - подтверждение что "не смогли в SQL". Если знали и не описали, ибо в статью слегка ломало - то что-то другое :)
Причем приблуда все равно использует существующие БД которуые так опускают в статье.
А вообще если бы статья не была бы чистой воды рекламой я бы сказал что её писали идиоты. А так, в принципе понятно зачем и почему так написано.


Ну строго говоря притягивать instead of триггеры сюда, это либо идиотизм, либо просто не понимание того пункта статьи. Я тут уже раз 5 все объяснил.

По факту было 2 косяка, это transition tables в PostgreSQL (да их действительно упустили) и CROSS APPLY, но второй это полукосяк: с View он помогает лишь частично, потому как непонятно что с LEFT JOIN (OUTER APPLY) делать (так как ON'а нет, а впихнуть условие соединения в WHERE как с CROSS APPLY не получится).

Ну и смысл статьи был не в том что отказаться от SQL, а доделать его и доделать нормально, а не как сейчас.
13 авг 19, 23:06    [21948684]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
invm
Member

Откуда: Москва
Сообщений: 8717
Nitro_Junkie
потому как непонятно что с LEFT JOIN (OUTER APPLY) делать (так как ON'а нет, а впихнуть условие соединения в WHERE как с CROSS APPLY не получится)
Мда, прежде чем писать подобные статьи, надо, все-таки, владеть предметом...
SELECT shipmentDetail.id, b.quantity
	FROM shipmentDetail 
	JOIN shipment ON shipmentDetail.shipment = shipment.id
	outer apply (select quantity from balance(shipment.date) where stock = shipment.stock AND product = shipmentDetail.product) b
	WHERE shipmentDetail.quantity = 5
14 авг 19, 11:09    [21948927]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
invm
Nitro_Junkie
потому как непонятно что с LEFT JOIN (OUTER APPLY) делать (так как ON'а нет, а впихнуть условие соединения в WHERE как с CROSS APPLY не получится)
Мда, прежде чем писать подобные статьи, надо, все-таки, владеть предметом...
SELECT shipmentDetail.id, b.quantity
	FROM shipmentDetail 
	JOIN shipment ON shipmentDetail.shipment = shipment.id
	outer apply (select quantity from balance(shipment.date) where stock = shipment.stock AND product = shipmentDetail.product) b
	WHERE shipmentDetail.quantity = 5


Хм.. Громоздко конечно, но прокатит, сейчас дополню статью.

В любом случае этот запрос у вас не выполнится, потому как план с nested loop будет, я дополнил это уже в статье.
14 авг 19, 11:48    [21948985]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6447
Nitro_Junkie,

автор
В любом случае этот запрос у вас не выполнится, потому как план с nested loop будет, я дополнил это уже в статье.

это потому что планы с NL никогда не выполняются?
14 авг 19, 11:51    [21948991]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
TaPaK
Nitro_Junkie,

автор
В любом случае этот запрос у вас не выполнится, потому как план с nested loop будет, я дополнил это уже в статье.

это потому что планы с NL никогда не выполняются?

Если там 10к записей то нет. Я не дождался во всяком случае выполнения вот такого запроса:
SELECT shipmentDetail.id, b.quantity
	FROM shipmentDetail 
	JOIN shipment ON shipmentDetail.shipment = shipment.id
	outer apply (select quantity from balance(shipment.date) where stock = shipment.stock AND product = shipmentDetail.product) b
	WHERE shipmentDetail.id%1000 = 0
14 авг 19, 12:04    [21949019]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Konst_One
Member

Откуда:
Сообщений: 11429
shipmentDetail.id%1000

извращение ещё то, вы как будто специально ставите сервер в позу своими запросами
14 авг 19, 12:07    [21949025]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Konst_One
shipmentDetail.id%1000

извращение ещё то, вы как будто специально ставите сервер в позу своими запросами


Тут любое условие где >10к записей подойдет.
14 авг 19, 12:08    [21949026]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6639
Nitro_Junkie,

и на какую оптимизация Вы рассчитываете в этом условии?

WHERE shipmentDetail.id%1000 = 0
14 авг 19, 12:11    [21949034]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
invm
Member

Откуда: Москва
Сообщений: 8717
Nitro_Junkie
потому как план с nested loop будет
Серьезно?
+
use tempdb;
go

create table dbo.t1 (id int primary key, dt datetime, a int);
create table dbo.t2 (id int primary key, t1_id int, dt datetime, b int);

update statistics dbo.t1 with rowcount = 100000;
update statistics dbo.t2 with rowcount = 10000000;
go

create function dbo.fn1
(
 @dt datetime
)
returns table
as
return
 select
  id, dt, t1_id, b
 from
  dbo.t2
 where
  dt = @dt;
go

set statistics profile on;

select
 a.id, a.a, b.b
from
 dbo.t1 a outer apply
 (select b from dbo.fn1(a.dt) where t1_id = a.id) b;

set statistics profile off;
go

drop function dbo.fn1;
drop table dbo.t1, dbo.t2;
go

select   a.id, a.a, b.b  from   dbo.t1 a outer apply   (select b from dbo.fn1(a.dt) where t1_id = a.id) b
|--Parallelism(Gather Streams)
|--Hash Match(Left Outer Join, HASH:([a].[dt], [a].[id])=([tempdb].[dbo].[t2].[dt], [tempdb].[dbo].[t2].[t1_id]), RESIDUAL:([tempdb].[dbo].[t2].[dt]=[tempdb].[dbo].[t1].[dt] as [a].[dt] AND [tempdb].[dbo].[t2].[t1_id]=[tempdb].[dbo].[t1].[id] as [a].[id]))
|--Bitmap(HASH:([a].[dt], [a].[id]), DEFINE:([Bitmap1004]))
| |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([a].[dt], [a].[id]))
| |--Clustered Index Scan(OBJECT:([tempdb].[dbo].[t1].[PK__t1__3213E83F86CDC1E6] AS [a]))
|--Compute Scalar(DEFINE:([Expr1003]=[tempdb].[dbo].[t2].[b]))
|--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([tempdb].[dbo].[t2].[dt], [tempdb].[dbo].[t2].[t1_id]))
|--Clustered Index Scan(OBJECT:([tempdb].[dbo].[t2].[PK__t2__3213E83F436C000F]), WHERE:(PROBE([Bitmap1004],[tempdb].[dbo].[t2].[dt],[tempdb].[dbo].[t2].[t1_id])))


ЗЫ: Гарантированный NL будет, если в в apply или в функции будет select top(...) ...
14 авг 19, 12:15    [21949046]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Владислав Колосов
Nitro_Junkie,

и на какую оптимизация Вы рассчитываете в этом условии?

WHERE shipmentDetail.id%1000 = 0


На то что hash join будет. Как если грубо говоря сделать:

SELECT shipmentDetail.id, b.quantity
	FROM shipmentDetail 
	JOIN shipment ON shipmentDetail.shipment = shipment.id
	LEFT JOIN balance(shipment.date) ON stock = shipment.stock AND product = shipmentDetail.product b
	WHERE shipmentDetail.id%1000 = 0


А если быть точным, вот так, как делает lsFusion:

SELECT shipmentDetail.id, b.quantity
	FROM shipmentDetail 
	JOIN shipment ON shipmentDetail.shipment = shipment.id
	JOIN (SELECT stock, product, dates.date, SUM(quantity) AS quantity
		FROM
			(SELECT receipt.stock, product, receipt.date, quantity
			FROM receiptDetail 
				JOIN receipt ON receiptDetail.receipt = receipt.id
			UNION ALL 
			SELECT shipment.stock, product, shipment.date, -quantity
				FROM shipmentDetail 
				JOIN shipment ON shipmentDetail.shipment = shipment.id
			) details
		JOIN 
			(SELECT shipment.date
				FROM shipmentDetail 
				JOIN shipment ON shipmentDetail.shipment = shipment.id
				WHERE shipmentDetail.id %1000 = 0
				GROUP BY shipment.date
			) dates ON details.date < dates.date
		GROUP BY stock, product, dates.date
	) b ON b.stock = shipment.stock AND b.product = shipmentDetail.product AND b.date = shipment.date
	WHERE shipmentDetail.id %1000 = 0


Это все есть в статье, к которой тут все норовят придраться.
14 авг 19, 12:16    [21949048]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
invm
Nitro_Junkie
потому как план с nested loop будет
Серьезно?
+
use tempdb;
go

create table dbo.t1 (id int primary key, dt datetime, a int);
create table dbo.t2 (id int primary key, t1_id int, dt datetime, b int);

update statistics dbo.t1 with rowcount = 100000;
update statistics dbo.t2 with rowcount = 10000000;
go

create function dbo.fn1
(
 @dt datetime
)
returns table
as
return
 select
  id, dt, t1_id, b
 from
  dbo.t2
 where
  dt = @dt;
go

set statistics profile on;

select
 a.id, a.a, b.b
from
 dbo.t1 a outer apply
 (select b from dbo.fn1(a.dt) where t1_id = a.id) b;

set statistics profile off;
go

drop function dbo.fn1;
drop table dbo.t1, dbo.t2;
go

select   a.id, a.a, b.b  from   dbo.t1 a outer apply   (select b from dbo.fn1(a.dt) where t1_id = a.id) b
|--Parallelism(Gather Streams)
|--Hash Match(Left Outer Join, HASH:([a].[dt], [a].[id])=([tempdb].[dbo].[t2].[dt], [tempdb].[dbo].[t2].[t1_id]), RESIDUAL:([tempdb].[dbo].[t2].[dt]=[tempdb].[dbo].[t1].[dt] as [a].[dt] AND [tempdb].[dbo].[t2].[t1_id]=[tempdb].[dbo].[t1].[id] as [a].[id]))
|--Bitmap(HASH:([a].[dt], [a].[id]), DEFINE:([Bitmap1004]))
| |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([a].[dt], [a].[id]))
| |--Clustered Index Scan(OBJECT:([tempdb].[dbo].[t1].[PK__t1__3213E83F86CDC1E6] AS [a]))
|--Compute Scalar(DEFINE:([Expr1003]=[tempdb].[dbo].[t2].[b]))
|--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([tempdb].[dbo].[t2].[dt], [tempdb].[dbo].[t2].[t1_id]))
|--Clustered Index Scan(OBJECT:([tempdb].[dbo].[t2].[PK__t2__3213E83F436C000F]), WHERE:(PROBE([Bitmap1004],[tempdb].[dbo].[t2].[dt],[tempdb].[dbo].[t2].[t1_id])))


ЗЫ: Гарантированный NL будет, если в в apply или в функции будет select top(...) ...


Гарантированный NL в данном случае будет (а не вообще). Когда у вас есть параметр, для которого таблицы и предиката = нет (есть только на >, < типа остатка / задолженности на дату как в примере).
14 авг 19, 12:19    [21949056]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6639
Nitro_Junkie,

автор
как делает lsFusion


Хм, это очень плохой запрос, поднять его производительность можно только методом грубой силы (оборудованием). В нем есть и сортировки, и просмотры, предполагаю, что и параллельный план выполнения не может быть для него построен.
14 авг 19, 12:33    [21949093]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
invm
Member

Откуда: Москва
Сообщений: 8717
Nitro_Junkie
Гарантированный NL в данном случае будет (а не вообще). Когда у вас есть параметр, для которого таблицы и предиката = нет
Когда нет предиката эквивалентности как раз и будет гарантиролванный NL, что для join, что для apply.
14 авг 19, 12:37    [21949099]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
Владислав Колосов
Nitro_Junkie,

автор
как делает lsFusion


Хм, это очень плохой запрос, поднять его производительность можно только методом грубой силы (оборудованием). В нем есть и сортировки, и просмотры, предполагаю, что и параллельный план выполнения не может быть для него построен.


Ну он точно лучше чем базовый (который вешает все намертво). И хорошо параллелится (с чего вдруг он не должен этого делать).
14 авг 19, 12:49    [21949120]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
invm
Nitro_Junkie
Гарантированный NL в данном случае будет (а не вообще). Когда у вас есть параметр, для которого таблицы и предиката = нет
Когда нет предиката эквивалентности как раз и будет гарантиролванный NL, что для join, что для apply.


Когда есть предикат эквивалентности то и UDF и APPLY не нужны. Можно построить обычный VIEW, просто с join'ить его а Join Predicate Push Down все сам сделает. А смысл пункта в статье именно в таких параметрах.
14 авг 19, 12:51    [21949124]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
invm
Member

Откуда: Москва
Сообщений: 8717
Nitro_Junkie
Когда есть предикат эквивалентности то и UDF и APPLY не нужны.
А когда нету, то нужны?

Вы просто не знаете как решать подобные задачи.
CREATE FUNCTION balance (
    @date DATE,
    @stock ... = null,
    @product ... = null
)
RETURNS TABLE
AS
RETURN
SELECT stock, product, SUM(quantity) AS quantity
	FROM
		(SELECT receipt.stock, product, quantity
		FROM receiptDetail 
			JOIN receipt ON receiptDetail.receipt = receipt.id
			WHERE @stock is null and @product is null and receipt.date < @date
		UNION ALL 
		SELECT receipt.stock, product, quantity
		FROM receiptDetail 
			JOIN receipt ON receiptDetail.receipt = receipt.id
			WHERE @stock is not null and @product is not null and receipt.date < @date and stock = @stock and product = @product
		UNION ALL 
        SELECT shipment.stock, product, -quantity
			FROM shipmentDetail 
			JOIN shipment ON shipmentDetail.shipment = shipment.id
			WHERE @stock is null and @product is null and shipment.date < @date
		UNION ALL 
        SELECT shipment.stock, product, -quantity
			FROM shipmentDetail 
			JOIN shipment ON shipmentDetail.shipment = shipment.id
			WHERE @stock is not null and @product is not null and shipment.date < @date) details and stock = @stock and product = @product
	GROUP BY stock, product

SELECT shipmentDetail.id, b.quantity
	FROM shipmentDetail 
	JOIN shipment ON shipmentDetail.shipment = shipment.id
	outer apply balance(shipment.date, shipment.stock, shipmentDetail.product) b
	WHERE shipmentDetail.id%1000 = 0
14 авг 19, 13:29    [21949182]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
invm
Nitro_Junkie
Когда есть предикат эквивалентности то и UDF и APPLY не нужны.
А когда нету, то нужны?

Вы просто не знаете как решать подобные задачи.
CREATE FUNCTION balance (
    @date DATE,
    @stock ... = null,
    @product ... = null
)
RETURNS TABLE
AS
RETURN
SELECT stock, product, SUM(quantity) AS quantity
	FROM
		(SELECT receipt.stock, product, quantity
		FROM receiptDetail 
			JOIN receipt ON receiptDetail.receipt = receipt.id
			WHERE @stock is null and @product is null and receipt.date < @date
		UNION ALL 
		SELECT receipt.stock, product, quantity
		FROM receiptDetail 
			JOIN receipt ON receiptDetail.receipt = receipt.id
			WHERE @stock is not null and @product is not null and receipt.date < @date and stock = @stock and product = @product
		UNION ALL 
        SELECT shipment.stock, product, -quantity
			FROM shipmentDetail 
			JOIN shipment ON shipmentDetail.shipment = shipment.id
			WHERE @stock is null and @product is null and shipment.date < @date
		UNION ALL 
        SELECT shipment.stock, product, -quantity
			FROM shipmentDetail 
			JOIN shipment ON shipmentDetail.shipment = shipment.id
			WHERE @stock is not null and @product is not null and shipment.date < @date) details and stock = @stock and product = @product
	GROUP BY stock, product

SELECT shipmentDetail.id, b.quantity
	FROM shipmentDetail 
	JOIN shipment ON shipmentDetail.shipment = shipment.id
	outer apply balance(shipment.date, shipment.stock, shipmentDetail.product) b
	WHERE shipmentDetail.id%1000 = 0


Это вы к чему? Я имел ввиду что если бы запрос был на равенство date, то ни UDF ни APPLY не нужны были бы, можно было бы VIEW и JOIN обойтись.

Ну и в том что вы кинули тот же дурацкий план с nested loops:

SELECT shipmentDetail.id, b.quantity   FROM shipmentDetail    JOIN shipment ON shipmentDetail.shipment = shipment.id   outer apply pbalance(shipment.date, shipment.stock, shipmentDetail.product) b   WHERE shipmentDetail.id%1000 = 0 OPTION (MAXDOP 1)
  |--Nested Loops(Left Outer Join, OUTER REFERENCES:([test].[dbo].[shipmentdetail].[product], [test].[dbo].[shipment].[date], [test].[dbo].[shipment].[stock]))
       |--Hash Match(Inner Join, HASH:([test].[dbo].[shipmentdetail].[shipment])=([test].[dbo].[shipment].[id]))
       |    |--Index Scan(OBJECT:([test].[dbo].[shipmentdetail].[shipmentdetail_p_s]),  WHERE:([test].[dbo].[shipmentdetail].[id]%(1000)=(0)))
       |    |--Clustered Index Scan(OBJECT:([test].[dbo].[shipment].[PK__shipment__3213E83F4B7B4D07]))
       |--Compute Scalar(DEFINE:([Expr1025]=CASE WHEN [Expr1033]=(0) THEN NULL ELSE [Expr1034] END))
            |--Stream Aggregate(DEFINE:([Expr1033]=COUNT_BIG([Union1024]), [Expr1034]=SUM([Union1024])))
                 |--Concatenation
                      |--Nested Loops(Inner Join, OUTER REFERENCES:([test].[dbo].[receiptdetail].[receipt]))
                      |    |--Nested Loops(Inner Join, OUTER REFERENCES:([test].[dbo].[receiptdetail].[id]))
                      |    |    |--Filter(WHERE:(STARTUP EXPR([test].[dbo].[shipment].[stock] IS NULL AND [test].[dbo].[shipmentdetail].[product] IS NULL)))
                      |    |    |    |--Index Seek(OBJECT:([test].[dbo].[receiptdetail].[receiptdetail_product_fk]), SEEK:([test].[dbo].[receiptdetail].[product]=[test].[dbo].[shipmentdetail].[product]) ORDERED FORWARD)
                      |    |    |--Clustered Index Seek(OBJECT:([test].[dbo].[receiptdetail].[PK__receiptd__3213E83FE8063B8C]), SEEK:([test].[dbo].[receiptdetail].[id]=[test].[dbo].[receiptdetail].[id]) LOOKUP ORDERED FORWARD)
                      |    |--Clustered Index Seek(OBJECT:([test].[dbo].[receipt].[PK__receipt__3213E83FE2F580DF]), SEEK:([test].[dbo].[receipt].[id]=[test].[dbo].[receiptdetail].[receipt]),  WHERE:([test].[dbo].[receipt].[stock]=[test].[dbo].[shipment].[stock] AND [test].[dbo].[receipt].[date]<[test].[dbo].[shipment].[date]) ORDERED FORWARD)
                      |--Nested Loops(Inner Join, OUTER REFERENCES:([test].[dbo].[receiptdetail].[receipt]))
                      |    |--Filter(WHERE:(STARTUP EXPR([test].[dbo].[shipment].[stock] IS NOT NULL AND [test].[dbo].[shipmentdetail].[product] IS NOT NULL)))
                      |    |    |--Index Spool(SEEK:([test].[dbo].[receiptdetail].[product]=[test].[dbo].[shipmentdetail].[product]))
                      |    |         |--Clustered Index Scan(OBJECT:([test].[dbo].[receiptdetail].[PK__receiptd__3213E83FE8063B8C]))
                      |    |--Clustered Index Seek(OBJECT:([test].[dbo].[receipt].[PK__receipt__3213E83FE2F580DF]), SEEK:([test].[dbo].[receipt].[id]=[test].[dbo].[receiptdetail].[receipt]),  WHERE:([test].[dbo].[receipt].[stock]=[test].[dbo].[shipment].[stock] AND [test].[dbo].[receipt].[date]<[test].[dbo].[shipment].[date]) ORDERED FORWARD)
                      |--Nested Loops(Inner Join, OUTER REFERENCES:([test].[dbo].[shipmentdetail].[shipment], [Expr1031]) WITH UNORDERED PREFETCH)
                      |    |--Filter(WHERE:(STARTUP EXPR([test].[dbo].[shipment].[stock] IS NULL AND [test].[dbo].[shipmentdetail].[product] IS NULL)))
                      |    |    |--Index Spool(SEEK:([test].[dbo].[shipmentdetail].[product]=[test].[dbo].[shipmentdetail].[product]))
                      |    |         |--Compute Scalar(DEFINE:([Expr1016]= -[test].[dbo].[shipmentdetail].[quantity]))
                      |    |              |--Clustered Index Scan(OBJECT:([test].[dbo].[shipmentdetail].[PK__shipment__3213E83F996CFFF4]))
                      |    |--Clustered Index Seek(OBJECT:([test].[dbo].[shipment].[PK__shipment__3213E83F4B7B4D07]), SEEK:([test].[dbo].[shipment].[id]=[test].[dbo].[shipmentdetail].[shipment]),  WHERE:([test].[dbo].[shipment].[stock]=[test].[dbo].[shipment].[stock] AND [test].[dbo].[shipment].[date]<[test].[dbo].[shipment].[date]) ORDERED FORWARD)
                      |--Nested Loops(Inner Join, OUTER REFERENCES:([test].[dbo].[shipmentdetail].[shipment], [Expr1032]) WITH UNORDERED PREFETCH)
                           |--Filter(WHERE:(STARTUP EXPR([test].[dbo].[shipment].[stock] IS NOT NULL AND [test].[dbo].[shipmentdetail].[product] IS NOT NULL)))
                           |    |--Index Spool(SEEK:([test].[dbo].[shipmentdetail].[product]=[test].[dbo].[shipmentdetail].[product]))
                           |         |--Compute Scalar(DEFINE:([Expr1021]= -[test].[dbo].[shipmentdetail].[quantity]))
                           |              |--Clustered Index Scan(OBJECT:([test].[dbo].[shipmentdetail].[PK__shipment__3213E83F996CFFF4]))
                           |--Clustered Index Seek(OBJECT:([test].[dbo].[shipment].[PK__shipment__3213E83F4B7B4D07]), SEEK:([test].[dbo].[shipment].[id]=[test].[dbo].[shipmentdetail].[shipment]),  WHERE:([test].[dbo].[shipment].[stock]=[test].[dbo].[shipment].[stock] AND [test].[dbo].[shipment].[date]<[test].[dbo].[shipment].[date]) ORDERED FORWARD)
14 авг 19, 14:14    [21949276]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
invm
Member

Откуда: Москва
Сообщений: 8717
Nitro_Junkie
Ну и в том что вы кинули тот же дурацкий план с nested loops
План не дурацкий, а нормальный для вашей задачи. Ибо другого не будет.
Предложенные модификации позволят, при наличии соответствующих индексов, уменьшить объем перелопачиваемых данных.

Проблема у вас не в NL и плохости SQL, а в выбранной модели данных - отсутствует таблица текущего наличия. О чем уже не один раз писалось.
14 авг 19, 16:10    [21949401]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
invm
отсутствует таблица текущего наличия

Что за таблица текущего наличия?
14 авг 19, 16:45    [21949445]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
invm
Member

Откуда: Москва
Сообщений: 8717
Nitro_Junkie
Что за таблица текущего наличия?
Таблица, где хранятся текущие остатки.
14 авг 19, 16:49    [21949449]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
invm
Nitro_Junkie
Что за таблица текущего наличия?
Таблица, где хранятся текущие остатки.

Так мне нужны остатки на дату. А дата может быть и год назад. Чем мне текущие остатки то помогут?
14 авг 19, 17:01    [21949461]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
4d_monster
Member

Откуда: Москва
Сообщений: 1524
Nitro_Junkie
invm
пропущено...
Таблица, где хранятся текущие остатки.

Так мне нужны остатки на дату. А дата может быть и год назад. Чем мне текущие остатки то помогут?

Откройте для себя Регистр, а не изобретайте велосипед на треугольных колёсах.
14 авг 19, 17:06    [21949469]     Ответить | Цитировать Сообщить модератору
 Re: Проблема с оптимизацией IS NOT NULL  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1042
4d_monster
Nitro_Junkie
пропущено...

Так мне нужны остатки на дату. А дата может быть и год назад. Чем мне текущие остатки то помогут?

Откройте для себя Регистр, а не изобретайте велосипед на треугольных колёсах.


Это в Oracle или в MS SQL как называется? И даже если бы он был, чем мне он в этом запросе поможет? Ну не будет UNION ALL, но проблема то останется.
14 авг 19, 17:14    [21949478]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Microsoft SQL Server Ответить