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

Ключи нужны для создания реляционных связей. Но по идее, у вас уже есть связи в бизнес-логике. Вы зачем-то дублируете эти связи в БД, но по правилам БД, где не всё можно отобразить на бизнес-слой (и наоборот). А потом через слой работы с БД (ORM или ещё какой паттерн хранилища данных) сглаживаете углы и несовместимости. И вот у вас уже три слоя, с тремя моделями, которые все означают примерно одно и то же, при этом один слой существует вообще лишь для интеграции двух остальных.

Если бы можно было затолкать всю БД в оперативку, то и БД с ORM не понадобилось бы. Тем более, насколько мне известно, СУБД и так в своих оптимизациях держит наиболее часто выполняемые запросы или подзапросы в RAM (или что-то подобное - типа кеша).

То, что создатели баз данных пытаются на своих расширениях SQL целые приложения писать, это как некоторые фронтэндщики пытаются протолкнуть в CSS вычисления и далее продвинуть это, судя по всему, до ещё одного языка программирования. Расширения SQL были сделаны для того, чтобы немного облегчить работу DBA, а не позволить им писать полноценные приложения. Javascript и CSS были придуманы, чтобы немного облегчить жизнь создателям интернет-страничек, а не позволить им писать полноценные приложения. Но всё пошло не по плану...