А это вообще возможно? Без перемножения таблиц придётся дёргать join делать руками в своём коде, тоннами запросов.

Ну способ наверно есть, вот только он вряд ли сведётся к небольшим правкам существующего кода. Скорее надо будет переделать всю архитектуру.

так чтоли? только без left join'a

with
	x(ax,bx) as (values (1, 111),(2,222),(3,333)),
	y(ay,by) as (values (1, 1111),(2,2222),(3,3333)),
	z(az,bz) as (values (1, 11111),(2,22222))

select 0, * from x
inner join y on x.ax = y.ay
left join z on x.ax = z.az
union all
select 1, * from x, y, z
where x.ax = y.ay
and x.ax = z.az

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

Сказал бы хоть какая бд. Ну можно делать селект из каждой таблицы и джойнить руками, можно вынести джойны во вьюхи, можно переделать таблицы так чтобы они уже заджойненными лежали (одна таблица вместо двух). Выбирай.

По определенным причинам нельзя больше делать апдейты и селекты. Но уже написанна тьма кода на SQL, который их использует.

Есть ли способ, который позволит упростить SQL, выбросив оттуда апдейты и селекты, сведя их к более простым операциям?

лiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiл

.

GOLANG!

По определенным причинам нельзя больше делать джойны и экзисты

Можно озвучить эти непреодолимые причины?

хочу утилиту, которая распарсит SQL и автоматически превратит джойны в подзапросы

Переход на самопальную БД, которая не умеет в джойны.

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

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

Есть ли способ, который позволит АВТОМАТИЧЕСКИ упростить SQL, выбросив оттуда неэффективные операции и экзисты, сведя их к более простым операциям? Например, какая-то консольная утилита

Не, лучше вот так

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

Есть ли способ, который позволит АВТОМАТИЧЕСКИ улучшить код, выбросив оттуда говнокод, сведя их к более простому и эффективному коду? Например, какая-то консольная утилита

Есть ли способ, который позволит АВТОМАТИЧЕСКИ улучшить код, выбросив оттуда говнокод, сведя их к более простому и эффективному коду? Например, какая-то консольная утилита

vertexua

Дык есть такая утилита! rm :)

блин, зачем вы все это повторяете?

То что ты просишь невыполнимо (а именно превращение JOIN в какой-то другой запрос без JOIN и без полной материализации), вот мы и очень обеспокоены и советуем больше не подседать на реляционные СУБД. Сначала вроде легко, убеждаешь себя что можешь спрыгнуть, а потом оказывается что приложение не масштабируется и ты ничего не можешь сделать, кроме просьб о сочуствии на ЛОРе

Пипец, а вы не могли посчитать число джойнов до переезда на кривую самопальную БД?

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

Один ты меня понимаешь :(

Но ты забыл о возможности делать подселекты и последовательности селектов! Селектаем айдишники из одной таблички, селектаем из другой, результат пересекаем... Помойму так Hibernate работает в отдельных особо печальных случаях (типа когда у тебя enitity наследуются, то при операции удаления он сначала селектает айдишники удаляемых элементов во временную таблицу, и только второй операцией бежит по временной таблице и удаляет сущности по id)

Переход на самопальную БД, которая не умеет в джойны.

АХАХАХАХХАХАХА.

То есть.. Что только не делают люди, лишь бы не использовать postgresql.

Что только не делают люди, лишь бы не использовать postgresql

Скорее уж что только не делают люди, лишь бы не исправлять кривые запросы.

селектаем

не селектаем, а селектим ;)

Переход на самопальную БД, которая не умеет в джойны.

но зачем...?

ну как, select ... from t1, t2, t3 where t1.f = t2.f and ... and ... t3.f = t1.f

тоже самое.

Ну не факт что их самопальная БД и это сдюжит. Ну и если я правильно помню, это работает хуже, чем join.

Лучше бы ты в Axmor пошел работать. У нас там такой-то энтерпрайз, закачаешься, ммм.

Напиши прокладку, которая понимает SQL, а в качестве бэкенда использует вашу БД.

Напиши сам, будь мужиком.

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

http://memesmix.net/media/created/7gc6ik.jpg

Переход на самопальную БД, которая не умеет в джойны.

но зачем...?

veshestva-driven development

нельзя больше делать джойны и экзисты

Батюшка не велит?

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

Видимо, это даже не SQLite...

В смысле, написать автомат, который будет парсить избранные куски SQL? Но ведь это очень долго и сложно..

Кстати, что посоветуешь для такой вот задачи? Честно парсить SQL нафигачив грамматику на AntLR не очень радует, да и небыстро это будет в рантайме-то

vertexua верно угадал. Это нереляционная бд с SQL API.

А вы orm не использовали? Можно было бы orm переделать, чтобы она такое генерила.

Лично я фигачил бы на хаскеле. Цель не парсить sql полностью, а только джойны, так что должно быть достаточно просто. Да, в принципе, и полный разбор не сильно сложен.

Это нереляционная бд

Суровый работодатель...

Это реляционная бд

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

набижали хейтеры-sqlфобы!

Это не работодаель. О работе я не имею права писать в интернете. Это гальванизация нашего собственного проекта, код которого бесплатно был передан нам с одной из прошлых работ.

Я пока не буду распространяться о сути, но там хитрая приблуда, позволяющая работать с сотнями и тысячами серверов одновременно. Поднимите руки все sqlфаги, кто хоть раз настраивал догоняющую репликацию postgresql на пяти тысячах виртуалок, соединенных в один остров

SQL вообще язык всего навсего, он тут ни при чем. С помощью него например можно все равно отлично делать выборки и фильтры. Просто в реляционной модели ради карго-культа любят все нормализировать, а потом отгребать проблем. Вот если таким не упарываться, то даже тот же MySQL/PostgreSQL можно расшардить и использовать как нереляционки с сильной транзакционностью. Максимум реляционки внутри шардов. Но сама БД тебя провоцирует не думать о такой сложности сразу

Если у меня масштабирование головного мозга, то прошу прощения у участников дискуссии. Не мы такие, жизнь такая

Поднимите руки все sqlфаги, кто хоть раз настраивал догоняющую репликацию postgresql на пяти тысячах виртуалок, соединенных в один остров

в чём практический смысл этим заниматься?

кто хоть раз настраивал догоняющую репликацию postgresql на пяти тысячах виртуалок, соединенных в один остров

Ммм, хм, оно как вообще должно работать то? Нужно какое-то гигинтское масштабирование на чтение? Не ясно кто кого догонять будет

Да нет такого инструмента, а был бы - я бы не рекомендовал использовать. Все равно же проверять придется.

Почему бы не переехать сразу на ОРМ ? Даже в виде самопальных оберток.

Есть ли способ

Нет, только руками. Иди работай уже.

Поднимите руки все sqlфаги, кто хоть раз настраивал догоняющую репликацию postgresql на пяти тысячах виртуалок, соединенных в один остров

Я не настраивал. :) Но всё же, ты уверен, что виновата именно реляционная модель, и если да, то почему?

он думал, что его от этого попустит. а вышло.. ну вот как-то так вышло

ну если у вас там прям суровые хайлоад, что я бы взял в руки bnf, jflex и попробовал бы асилить разбор. думаю даже есть готовые решения, select ... join так точно должны быть а большего вам и не надо.