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

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

Откуда:
Сообщений: 806
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

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


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



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


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

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

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

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

Откуда:
Сообщений: 1090
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

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

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

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

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

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

Откуда:
Сообщений: 806
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

Откуда:
Сообщений: 1090
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

Откуда:
Сообщений: 1090
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

Откуда: Москва
Сообщений: 1162
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

Откуда:
Сообщений: 806
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

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

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

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

Откуда:
Сообщений: 1090
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

Откуда:
Сообщений: 1090
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

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


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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

Откуда:
Сообщений: 1090
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

Откуда: Москва
Сообщений: 9646
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

Откуда:
Сообщений: 1090
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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: ←Ctrl  назад   1 [2] 3   вперед  Ctrl→      все
Все форумы / Microsoft SQL Server Ответить