JOIN как в ORM: связи по foreign key в PostgreSQL

как её понимаю я и многие те кто задавался этим вопросом, писал спфецификации и реализовывал во всех текущих СУБД. Про всё про это указано в моей статье.
У меня ни коим образом не трогает сам язык, а дополняет уже готовыми функциями, которыми можно пользоваться хоть в дополнение, хоть без хоть с ними. Сам функционал нативный для PG

JOIN как в ORM: связи по foreign key в PostgreSQL

Ошибаетесь в RDBMS - relation это именно связь между данными, сама таблица без связей просто данные, без R

JOIN как в ORM: связи по foreign key в PostgreSQL

Статья о том, что вся идеология SQL стремилась получить соединение по связям. Я же процитировал ниже свою же статью:

https://habr.com/ru/articles/1065684/comments/#comment_30295142

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

JOIN как в ORM: связи по foreign key в PostgreSQL

Что характерно нет никакого этому подтверждения, потому что похоже в статье отсутствует план запроса до-после, или какой-либо бенчмарк. У джентельменов принято верить на слово, и если в pg в все именно так, то это замечательно, но к примеру в sql server использование методов.. смерти подобно потому что код в большинстве случаев не разматывается оптимизатором, как в случае вью или сахарных CTE.

Ошибаетесь, всё необходимые EXPLAIN'ы выполнены и ссылки приведены и корнер кейсы расписаны. Вы видимо читали статью по-диагонали.

Вот эксплейны:

https://github.com/asmgit/pg_relation_sql/blob/main/EXPLAIN.md

Ссылка есть в статье

Корнер кейсы честно разобраны в разделе "Честные ограничения"

Про нейминг вы видимо тоже не прочитали.

.. я не большой специалист в Pg, но это выглядит так словно мы одной нагой залезли в N+1 проблему. Делать это преимуществом по сравнению с JOIN.. ну такое. В принципе это не проблема для подможества, где использование LATERAL это норма.

Опять же направляю Вас посмотреть EXPLAIN ссылку и почитать правила инлайна в PG (тоже есть в статье). На этой синергии и построен мой удивительный модуль.

Последние ваши изыскания совсем сумбурны. Если хотите донести мысль, поясните.

JOIN как в ORM: связи по foreign key в PostgreSQL

Без первичных ключей это не база данных, это файл, это набор данных. Вся реляционная модель построена на ключах и связях. Реляция - связь!

JOIN как в ORM: связи по foreign key в PostgreSQL

Сомнительное утверждение. Тут я обычно цитирую Томаса Кайта с тестами доводами и опытом:

Эффективное проектирование приложений Oracle / Это база данных, а не свалка данных

https://www.rsdn.org/article/db/goodoraapp.xml#EZTAE

потеря 10% производительности при записи, очень редко когда стоят достоверности всего набора. Это исключительные таблицы, которые потом ложатся в реляционную модель.

JOIN как в ORM: связи по foreign key в PostgreSQL

и опять комментатор, который статью не внимательно читал

Всё это лежит в каталоге, и по этим объявлениям идёт подавляющее большинство реальных соединений — один из практиков в обсуждении на HN оценил эту долю в «95%+ моих джойнов»

JOIN как в ORM: связи по foreign key в PostgreSQL

Видимо не внимательно статью читали:

Сокращать условия соединения SQL пытался не раз. Все четыре попытки — мимо.

Запятая + WHERE. Досахарная эпоха: таблицы списком, условия в WHERE вперемешку с фильтрами. Забыл условие — получил декартово произведение, молча.

JOIN как в ORM: связи по foreign key в PostgreSQL

в статье же указано чего всем не хватило за всю историю развития SQL

• Многословие. Пять связей — пять ON, слово в слово пересказывающих схему.

• Тихие ошибки. ON примет любое равенство: ON d.id = di.item_id вместо document_id выполнится молча — типы совпали. Ошибка всплывёт данными, а не компиляцией.

• Потеря смысла. По ON a.x = b.y не видно: связь это или совпадение, кто родитель, размножатся ли строки в агрегате.

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

Очереди на PostgreSQL: антипаттерн или реальность жизни

Интересное решение
https://worker.graphile.org/

на синт тестах RPS 100к на вставку, 10к на разгребание очереди

Переезд с Nuxt 2 на Nuxt 3: почему для крупного интернет-магазина мы выбрали рерайт, а не миграцию

а как features/ органиованы?

Переезд с Nuxt 2 на Nuxt 3: почему для крупного интернет-магазина мы выбрали рерайт, а не миграцию

А можете показать структуру FSD папок?

Кажется что для этого можно использовать папку Nuxt
~~/layers

https://nuxt.com/docs/4.x/getting-started/layers

Ошибки, которые можно избежать в SQL: грабли начинающего аналитика

а кое где это будет соединение по ключу (если он есть)

Суд в Москве оштрафовал Google на 8 млрд руб. за неуплату штрафов

Не вижу проблемы у Google:

1. в России 100M+ населения имеющего телефоны

2. каждый имеет 1+ телефон

3. Google брикает андроид

4. собирает 50р за анлок

5. Штраф уплачен

6. !!!PROFIT!!!

Триггеры в PostgreSQL: основы

Мощь Postgress в красивой реализации триггеров уровня STATEMENT

Решаем загадку Джиндоша из Dishonored 2 на SQL перебором с возвратом

WITH Positions(pos) AS (
    VALUES ROW(1), ROW(2), ROW(3), ROW(4), ROW(5)
)
, Names(name) AS (
    VALUES ROW('Winslow'), ROW('Marcolla'), ROW('Contee'), ROW('Natsiou'), ROW('Finch')
)
, Colors(color) AS (
    VALUES ROW('red'), ROW('white'), ROW('purple'), ROW('blue'), ROW('green')
)
, Cities(city) AS (
    VALUES ROW('Bailton'), ROW('Serkonos'), ROW('Freiport'), ROW('Morley'), ROW('Danuol')
)
, Drinks(drink) AS (
    VALUES ROW('absent'), ROW('coctail'), ROW('rum'), ROW('cider'), ROW('whiskey')
)
, Items(item) AS (
    VALUES ROW('ring'), ROW('diamond'), ROW('order'), ROW('cigar-case'), ROW('coulomb')
)
, s AS (
    SELECT DISTINCT *
    FROM Positions, Names, Items, Colors, Drinks, Cities
    WHERE ((name='Winslow' AND color = 'blue') OR (name!='Winslow' AND color != 'blue'))
    AND
    ((name='Marcolla' AND pos = 1) OR (name!='Marcolla' AND pos != 1))
    AND
    ((color='white' AND pos = 2) OR (color!='white' AND pos != 2))
    AND
    ((color='red' AND drink = 'whiskey') OR (color!='red' AND drink != 'whiskey'))
    AND
    ((city='Morley' AND color = 'green') OR (city!='Morley' AND color != 'green'))
    AND
    ((name='Finch' AND item = 'coulomb') OR (name!='Finch' AND item != 'coulomb'))
    AND
    ((city='Freiport' AND item = 'ring') OR (city!='Freiport' AND item != 'ring'))
    AND
    ((name='Contee' AND drink = 'absent') OR (name!='Contee' AND drink != 'absent'))
    AND
    ((city='Serkonos' AND drink = 'cider') OR (city!='Serkonos' AND drink != 'cider'))
    AND
    ((pos=3 AND drink = 'rum') OR (pos!=3 AND drink != 'rum'))
    AND
    ((name='Natsiou' AND city = 'Bailton') OR (name!='Natsiou' AND city != 'Bailton'))
)
SELECT t1.name, t1.item, t2.name, t2.item, t3.name, t3.item, t4.name, t4.item, t5.name, t5.item
FROM s t1
JOIN s t2 ON t2.name != t1.name AND t2.item != t1.item AND t2.color != t1.color AND t2.drink != t1.drink AND t2.city != t1.city
JOIN s t3 ON t3.name NOT IN (t1.name, t2.name)
  AND t3.item NOT IN (t1.item, t2.item)
  AND t3.color NOT IN (t1.color, t2.color)
  AND t3.drink NOT IN (t1.drink, t2.drink)
  AND t3.city NOT IN (t1.city, t2.city)
JOIN s t4 ON t4.name NOT IN (t1.name, t2.name, t3.name)
 AND t4.item NOT IN (t1.item, t2.item, t3.item)
 AND t4.color NOT IN (t1.color, t2.color, t3.color)
 AND t4.drink NOT IN (t1.drink, t2.drink, t3.drink)
 AND t4.city NOT IN (t1.city, t2.city, t3.city)
JOIN s t5 ON t5.name NOT IN (t1.name, t2.name, t3.name, t4.name)
 AND t5.item NOT IN (t1.item, t2.item, t3.item, t4.item)
 AND t5.color NOT IN (t1.color, t2.color, t3.color, t4.color)
 AND t5.drink NOT IN (t1.drink, t2.drink, t3.drink, t4.drink)
 AND t5.city NOT IN (t1.city, t2.city, t3.city, t4.city)
WHERE
-- Мы хотим вывести дам в том порядке, в котором они сидели
t1.pos = 1 AND t2.pos=2 AND t3.pos = 3 AND t4.pos=4 AND t5.pos=5
-- Дама в красном сидит левее дамы в пурпурном, но место 2 занято дамой в белом, поэтому остаются места 3 и 4
AND (
   (t3.color='red' AND t4.color='purple' ) OR (t4.color='red' AND t5.color='purple')
 )
-- Рядом с дамой с портсигаром сидит дама из Морли
AND
 (
   (t1.item='cigar-case' AND t2.city='Morley') OR
   (t2.item='cigar-case' AND 'Morley' IN (t1.city, t3.city)) OR
   (t3.item='cigar-case' AND 'Morley' IN (t2.city, t4.city)) OR
   (t4.item='cigar-case' AND 'Morley' IN (t3.city, t5.city)) OR
   (t5.item='cigar-case' AND t4.city='Morley')
 )
-- Рядом с дамой с бриллиантом сидит дама из Дануолл
AND
 (
   (t1.item='diamond' AND t2.city='Danuol') OR
   (t2.item='diamond' AND 'Danuol' IN (t1.city, t3.city)) OR
   (t3.item='diamond' AND 'Danuol' IN (t2.city, t4.city)) OR
   (t4.item='diamond' AND 'Danuol' IN (t3.city, t5.city)) OR
   (t5.item='diamond' AND t4.city='Danuol')
 )
-- Рядом с дамой из Дануолла другая дама пила коктейль
AND
 (
   (t1.drink='coctail' AND t2.city='Danuol') OR
   (t2.drink='coctail' AND 'Danuol' IN (t1.city, t3.city)) OR
   (t3.drink='coctail' AND 'Danuol' IN (t2.city, t4.city)) OR
   (t4.drink='coctail' AND 'Danuol' IN (t3.city, t5.city)) OR
   (t5.drink='coctail' AND t4.city='Danuol')
 )

MySQL 8, 1.81ms

EXPLAIN ANALYZE
....
-> Filter: ((((t4.color = 'purple') ........city))) (cost=852 rows=0.0682) (actual time=1.81..1.82 rows=1 loops=1)

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

Нашёл подобное приемлемое решение на MySQL как закапиталайзить предложение

WITH d AS (
    SELECT 'Lorem Ipsum is simply dummy text of the printing and typesetting industry.' s
)
, d2 AS (
    SELECT *
    , CONCAT(LOWER(s), UPPER(s)) s_l_u
    , CONCAT('(?<=[[:space:]]|^)[a-z](?=.{', (CHAR_LENGTH(s) - 1), '}([A-Z]))') reg_exp
    , CHAR_LENGTH(s) len
    FROM d
)
SELECT version() ver, s, SUBSTR(REGEXP_REPLACE(s_l_u, reg_exp, '$1'), 1, len) cap
FROM d2

+------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+
|ver   |s                                                                         |cap                                                                       |
+------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+
|8.0.35|Lorem Ipsum is simply dummy text of the printing and typesetting industry.|Lorem Ipsum Is Simply Dummy Text Of The Printing And Typesetting Industry.|
+------+--------------------------------------------------------------------------+--------------------------------------------------------------------------+

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/