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

Запрос:




План запроса:



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

И странно что Oracle отлично разруливает эту проблему.

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

Ну так запрос выполняется 3 секунды. А у Oracle 30мс.

Konst_Oneoracle != mssql - запомните и дальше станет проще

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

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

Я когда тестировал три базы, и мне надо было что-то проверить на Oracle я понимал, что а) логику надо выключить, б) приготовиться долбаться с ним в раза 4 больше чем с остальными.

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

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

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

Вот это странно, потому как триггеры в MS SQL имхо сделаны лучше чем в оракл. Во всяком случае там N+1 проблему победили. И многие ораклоиды поэтому мне говорили, что стараются избегать триггеров.

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

А что там такого особенного в архитектуре. Там же просто документы/ остатки и т.п. Или вы что-то другое имеете ввиду?

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

А как если не секрет по вашему нужно было структуру таблиц в данном случае организовывать?

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


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

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

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


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

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

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

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

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

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

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

invmNitro_JunkieЕсли бы можно было сделать триггер на представление balance все делалось бы одной строчкой.Ну так делайте. Или что-то мешает?
MS SQL не дает триггеры на представления делать.

Владислав КолосовNitro_Junkie,




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

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

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

SQL Server (15.0.1700.37) это 2019 preview как я понимаю. Но на эту проблему мне на всех серверах жаловались.

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


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


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

Представление определяет что мы хотим получить. Как это представление должно обновляться уже задача SQL сервера. То что они этого не умеют делать, ну значит руки не из того места растут. В том же lsFusion так можно делать.

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

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

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


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

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

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

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

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

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

А вообще мы это все реализовали в lsFusion.

PizzaPizzaВсегда удивляют изобретатели SQL

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


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

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

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


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

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

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

PizzaPizzaА писать можно хоть на ассемблере.
Но почему-то не пишут. А знаете почему? Потому что время разработчика в современном мире очень дорогое.

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

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

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

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

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

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

INSTEAD OF это по сути не триггеры. Они просто называются тем же словом.

andy stNitro_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 оставьте нематериализованным и используйте его.

andy stNitro_Junkie,
еще на заметку, в SQL Server есть такая фишка

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

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

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

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

Поэтому в идеале как можно больше должен делать сам сервер. В том числе в идеале добавлять материализации и определять расположение в таблицах. Хотя до этого даже мы не дошли пока. Но хотя бы сделали эти механизмы прозрачными.

MegabyteНу что, когда ждать смерти SQL? Есть примерные сроки?

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

Хотя смерть в данном контексте неправильное слово. Мы же не говорим о смерте машинных кодов. Просто есть абстракции компилируемые в этот машинный код. А сами машинные коды - живее всех живых.

Mindandy stNitro_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, а доделать его и доделать нормально, а не как сейчас.

invmNitro_Junkieпотому как непонятно что с LEFT JOIN (OUTER APPLY) делать (так как ON'а нет, а впихнуть условие соединения в WHERE как с CROSS APPLY не получится)Мда, прежде чем писать подобные статьи, надо, все-таки, владеть предметом...



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

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

TaPaKNitro_Junkie,

авторВ любом случае этот запрос у вас не выполнится, потому как план с nested loop будет, я дополнил это уже в статье.
это потому что планы с NL никогда не выполняются?
Если там 10к записей то нет. Я не дождался во всяком случае выполнения вот такого запроса:

Konst_OneshipmentDetail.id%1000

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

Тут любое условие где >10к записей подойдет.