Смешивать таблицы и объекты - плохая идея, в первую очередь

потому что на практике реальный объект описывается комбинацией разных таблиц, и клиенту совершенно не интересно как он хранится в бд и почему именно так, как его туда сохранять. Это только в простых и маленьких ис можно напрямую мапить объекты вроде юзера на таблицы. У меня например юзер это десяток разных таблиц. И когда клиент споашивает, он вполне комфортно сшивается и отдается. А когда нужна часть юзера - отдается или меняется эта часть, другая даже не блокируется. Инкапсуляция хранения структуры внутри бд, и влияния логики изменения юзера на другие таблицы, полиморфизм юзеров, наследование через добавление свойств и методов доступа к новым типам юзеров. Кажется это и называется ооп, не так ли? Попытка натянуть ооп непосредственно на таблицы приводит новичков к хранению json полей, со всеми вытекающими побочными эффектами.

Не, это ответ в общем, но надо инкапсулировать на уровне БД. Я с этим не согласен, я думаю что инкапсуляция должны быть на более высоком уровне, чтобы обеспечить переносимость на другие БД. Но вопрос бы не про это. Вот вы ракладываете вашего кастомера по куче таблиц строго следуя реляционной модели. Но PG поддерживает и ОО. Т.е. вообще говоря, если правильно описать типы, можно все атрибуты юзера сохранить в одной таблице. Т.е чисто замапить OO модель на БД. В NoSQL так и делают, к слову. И гордятся этим 😊. Так вот и вопрос: где нибудь эти фичи PG используются как основа архитекруты или они на самом деле лишние?

чтобы обеспечить переносимость на другие БД чего?

Приложения.

я еще не видел чтобы кому-то понадобилась переносимость на другие субд, если ты конечно делаешь не попсовый фреймворк. Любая серьезная система будет глубоко завязана на особенности субд настолько, что ее будут долго и упорно переносить, как щас например некоторые крупные банки (не будем показывать пальцем) переносят постепенно свои подстстемы с оракла на пг.

Любая современная большая система дает выбор поддерживаемых СУБД. Пример - SAP

нет, вообще нет. В жизни это совершенно не так. Поддерживать две субд - это значит не поддерживать полностью ни одну из них. В результате получается 1с, сап или пхп-фреймворк для сайтов о литых дисках

Вы мне про жизнь хотите рассказать? Я занимаюсь внедрениями лет 30 на всяких случай и опыта с энтерпрайзами у меня весьма немало. Сейчас все серьезные поставщики предлагают несколько поддерживаемых ДБ на выбор. Понятно, что если речь не идет о софте от самих производителей ДВ.

Например?

А как же богомерзкая 1С? Коммерческие тиражируемые системы, как ни странно, таки имеют поддержку далеко не одной СУБД. Грамотно спроектированные - по через функциональный АПИ, более другие - по через известное в России место (выходное отверстие ЖКТ).

А, ну раз вы ставите в один ряд SAP и "пхп-фреймворк для сайтов о литых дисках" то вообщем уровень осведомленности зашкаливает.

внедрением чего, сапа?)

Я же чуть выше ответил

Вас чем-то обидел сап?

я ставлю в один ряд любую систему, которая может работать на ноутбуке главбуха. Не важно что это, для них достаточно даже склайта.

Гхм. Вы запускали SAP на ноутбуке? Это какой-же нужен ноутбук, однако 😊. Дружище, у них там по минимуму кластер из нескольких серверов.

очевидно, потому что логика сделана непонятно где, вместо эффективных хранимок, а возможности субд сводятся к хранилищу данных :)

Слушайте, я так много узнаю. SAP - неправильная архитектура. Наследование в ООП - это антипатерн. Я уже понял все с вами. Не могли бы вы пожалуйста не засорять своим бредом чат?