SQL HowTo: замена в строке по набору

не проблема сгенерить 3 уникальных разделителя
- между строкой и всеми заменами
- между поиском и заменой
- между группами замен
и использовать их для построения регулярки

SQL HowTo: замена в строке по набору

Можно значительно проще и экономнее на regexp

Пример на MySQL (на PG думаю будет аналогично):

WITH d AS (
    SELECT 'abcdaaabbbcccdcba' s
    , 'a,x;bb,y;ccc,z;' repls
    , 'xbcdxxxybzdcbx' test_res
)
, d2 AS (
    SELECT *, CONCAT(s, '\n', repls) s_ex
    FROM d
)
, d3 AS (
    SELECT *
    , SUBSTRING_INDEX(REGEXP_REPLACE(s_ex, '(?<search>[^\n]+)(?=.*?(\n|\n.*?;)\\\k<search>,(?<repl>[^;]+);)', '${repl}', 1, 0, 'm'), '\n', 1) res
    FROM d2 d
)
SELECT s, res
, res = test_res is_correct
, VERSION() ver
FROM d3

+-----------------+--------------+----------+-----+
|s                |res           |is_correct|ver  |
+-----------------+--------------+----------+-----+
|abcdaaabbbcccdcba|xbcdxxxybzdcbx|1         |8.3.0|
+-----------------+--------------+----------+-----+

SQL в качестве API

Автор явно не исследовал тренды
https://www.graphile.org/postgraphile/introduction/

ORM для реальных приложений не окупается

Конечно, конечно. Код не выдерживает никакой критики, особенно в рамках обсуждения СУБД.Первая строка кода выглядит многообещающе. Вторая, уже подозрительно. Глядя на третью, уже всё понимаешь: приложение даже не пробует получить какую-то блокировку на запись, оно просто читает, хотя из второй строчки кода складывается впечатление что мы будем писать "...Save... ...inputData". Смотришь дальше и волосы на голове начинают шевелиться, тем более что у Ларавеле есть метод что бы эти строки не писать - findOrFail. А пока мы над всем этим переживали, прилетевшие данные подлетели, посмотрели насчёт published статуса и перепрыгнули на сохранение, на 12 строке... Но сохранения никого не произошло, т.к. другая сессия уже удалила эти данные. Вот и сказочке конец, а один единственный UPDATE решил бы все эти проблемы чуть более чем полностью.
P.S. слава богу что не я

ORM для реальных приложений не окупается

Михаил, Михаил, столько времени прошло, а Вы тут с настолько позорным кодом выступаете в его поддержку....

Как был создан потоковый SQL-движок

батч режим-то не применишь, чтобы не каждый инсерт отрабатывать, а сразу большую пачку

В postgresql AFTER STATEMENT триггеры

Примерчик в конце
https://www.postgresql.org/docs/current/plpgsql-trigger.html

даст большую фору логике в приложении

Индексирование JSON в MySQL

Индексы по функции не всегда используются оптимизатором (баг MySQL)
https://bugs.mysql.com/bug.php?id=104928

Зачем айтишнику ехать в Екатеринбург

в 8-30 уже на горе

а там такая красота

Зачем айтишнику ехать в Екатеринбург

Моё любимое зимнее развлечение в Екб: с утра пораньше встаёшь, едешь на Уктус (20 минут от дома), бегаешь пешком в гору, катаешь на сноуборде часик-полтора, потом скатываешься к подножью горы и там ждёт Баден - горячие термы на открытом воздухе, пол дюжины различных саун + арома-парения раз в пол часа, за всё удовольствие 800р утренняя акция почти 2 часа терм с завтраком. Далее полчаса и ты дома свежий, бодрый, весёлый готов работать )))

Авторизация в PostgreSQL. Часть 2. Безопасность на уровне строк

Для себя пришёл к выводу, что для организации безопасности на уровне строк, удобнее использовать VIEW WITH CHECK OPTION. Это при SELECT'е дополнительно позволяет легко получить столбцы can_update, can_delete. При использовании встроенной RLS без дублирования логики сделать это не просто.

SQL и тайны коридоров Хогвартса

Константы != Служебные слова.

Второе встречается гораздо чаще.

Это что-то меняет?

Напомните, в каком языке до сих пор принято писать служебные слова в верхнем регистре?

SQL

SQL и тайны коридоров Хогвартса

• выполнение/редактирование кода в консоли

• чтение запросов в логе

во многих соглашениях прикладных ЯП принято константы писать большими буквами, не думаю что у многих при виде таких констант вспоминается 386 комп и BASIC.

С чем кушать Irregular Selectivity в MSSQL и не только

оптимизатор MySQL умеет такое кушать, но тоже оч ограниченно

Живи, умри, и снова: погружаемся в мир рогаликов

Очень нравятся рогалики, в последнее время залип в The Binding of Isaac, уже год оторваться не могу

Вместо 24 JOIN в SQL запросе — реализация в графовой базе данных

не надо сравнивать с EAV, спроектируйте нормальную структуру и сравните с ней, читаемость кода, быстродействие, консистентность

Вместо 24 JOIN в SQL запросе — реализация в графовой базе данных

Проблема тут не в SQL, а в EAV, т.е. неверно подобранном паттерне при проектировании схемы БД.

Валидация в приложении на PHP (часть 1 — валидация доменного слоя)

Вы не поняли, я как раз категорически против такого кода. Михаил, с которым мы дискутировали в той ветке, считает что подобным кодом и надо программировать, отгородившись от БД всякими ОРМ'ами. А в этом коде я на примере показал, что бывает если на прикладном языке начинать решать не свойственные для него задачи

Валидация в приложении на PHP (часть 1 — валидация доменного слоя)

можно строчку кода и как должно быть, по Вашему мнению

Валидация в приложении на PHP (часть 1 — валидация доменного слоя)

Не понял, какое место не нравится?

Валидация в приложении на PHP (часть 1 — валидация доменного слоя)

ну не миллион, а исключительную ситуацию, конгда фронт это пропустил, т.е. 1 на миллион
и опять же проверяться она же в любом случае, т.е. у Вас оверинжиниринг приветствуется