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 будет, я дополнил это уже в статье.