> Я еще студентом работал с клиентами по всему миру, собственно только на студентов такие вещи и срабатывают.

У меня такое ощущение, что вы недалеко от студенчества ушли. Может, ошибаюсь.

> Также просто как нарисовать сову.

Когда речь идёт о небольшом количестве запросов - очень просто. Сложность возникает с ростом их количества.

> Мы сделаем язык специально для управления данными, стандартизируем его чтобы всем было хорошо, но управлять данными не очень то получается не очень, так что сделаем еще один язык (диалект?). Получается как в ералаше "но чалма не действует вот без этой штуки".

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

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

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

> Я слышу эту параною с нулевых и она в основном беспочвенна. Если допустить что это правда, вендору гораздо проще отойти от SQL (например аменить одни токены на другие, вместо SELECT заставить писать GET например). Или продолжить использовать свой язык (вроде QUEL). Но этого не произошло.

У Оракла того же свой диалект SQL. Аналогов нет.
У остальных производителей СУБД та же или похожая ситуация.
Да, в целом все стремятся поддерживать стандарты. Но, как в том анекдоте "есть нюансы".

> стандарт (который напомню сделан специально для управления данными для БД) не покрывает необходимые возможности (о чем мы и сами пишите про PSQL)

PL/SQL для всех остальных задач, не для управления данными. Для управления данными - SQL.

> "Хорошо делай - хорошо будет", спасибо, кэп.

Всегда, пожалуйста. Просто многие забывают, что для того, чтобы делать хорошо, надо ещё знать немного побольше, чем основы. Но некоторые и основ не знают, и сразу в бой. Вот и получается в итоге, что надо постоянно рефакторингом структуры данных заниматься. Люди в таких проектах часто на интуицию пытаются полагаться, которая их всегда в итоге подводит. Это, как если бы студент какой сразу сел за написание кода с использованием любого языка программирования, не ознакомившись предварительно с существующими тонкостями, практиками, методологией. В итоге появляются книги, вроде "Совершенный код", которые учат жизни таких вот горе-специалистов. При работе со сложными структурами данных - то же самое соображение верно.

> Из моего опыта у 100% людей были проблемы с sql и они встречаются вплоть до опытных разработчиков.

Из моего опыта у этих людей до тех пор такие проблемы наблюдаются, пока они не возьмут хоть какую-то книжку по SQL, и не попытаются её хотя бы прочитать. Многие, видя простенькие SQL-запросы на каком-нибудь сайтике-обучалке, ошибочно полагают, что они уже всё знают, и больше им ничего не нужно. А некоторые вообще считают, что им SQL знать не нужно - за них прокси всё будет делать. На таких я насмотрелся за свою жизнь. Но ведь это отнюдь не означает, что SQL - суперсложен в изучении и последующем использовании.

> Внезапно с 4 уровнями иерархии в хорошо написанном коде обычно нет проблем с пониманием

Внезапно есть. Встречались книги от авторитетных авторов, где не рекомендовались иерархии более двух-трёх уровней - людям очень тяжело бывает разобраться, откуда появился тот или иной метод или свойство. А уж когда множественное наследие применяется - то и подавно.

> Вот именно, чтобы управлять данными приходится схему держать в голове

А вы как хотели, интересно? Почему-то 4 уровня иерархии в ООП для вас не проблема, хотя там тоже все классы надо в голове держать, чтобы понимать, что происходит. И вы не сможете разобраться в такой иерархии, пока не прошерстите весь код, который и в разных модулях может находиться.
А SQL-запрос, в котором сцепка всего из четырёх таблиц (причём все таблицы явно указаны в тексте запроса, включая метод сцепки) - проблема. Где логика?

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

Сильная связь - это, например, связь заголовка накладной с табличной частью? А как ещё избежать лишних данных при их хранении? Или всё в одну таблицу запихнуть предлагаете? Такой метод подойдёт, если данные не меняются - часто денормализация используется в хранилищах для ускорения работы запросов. А если меняются - задолбаетесь дополнительные проверки целостности писать.
Но допустим, вы объекты имеете ввиду. Как потом отчёты строить по вашей объектной структуре данных? Циклами? В таком случае, вы ничем не отличаетесь от моего начальника на той стадии, когда он не знал SQL и на простенький отчёт предлагал потратить 2-3 дня.

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

Нормализация таблиц (управление которыми вы назвали зоопарком) нужна для упрощения контроля целостности данных, при условии, что такие данные часто меняются. Обычно достаточно создать primary key, foreign key, навешать простенькие constraints, и СУБД сама будет всё контролировать вместо программиста, которому в противном случае пришлось бы писать простыни кода.

> это не дело на 5 минут

Это дело нескольких месяцев полноценного обучения. Да, я об этом уже говорил ранее. Но так в любой профессии. Странно, что вы акцент сделали именно на SQL при этом.

> Но как правило это экономит мое время (хотя казалось бы должно быть наоборот)

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

> не утруждая себя запоминанием волшебных оптимизаций для конкретных БД

Это очень редко когда надо делать на практике на самом деле. При условии, что изначально структура БД проектировалась не вчерашним студентом, само собой.

> мои десятки запросов очевидно менее эффективны в контексте нагрузки на базу чем один грамотно подготовленный мегазапрос

Всего лишь ОДИН из ваших запросов при сканировании большой таблицы в параллели вполне может ухайдокать сервер.

> связи между таблицами меня меньше всего интересуют

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