> общее представление данных - это практически калька с формата хранения этих данных в базе
Я бы наоборот сказал: представление данных в ORM как раз таки и приближенно максимально к любимым высокоуровневыми программистами сущностям, которые в программе удобно передать по ссылке целиком и вызвать у них методы. И связаны эти сущности в иерархические деревья с чёткой принадлежностью детей родителям. А в реляционку это потом упихивают ногами. А в произвольные проекции из произвольных джойнов для поиска по хитрым _взаимо_связям ORM умеет очень плохо, ну так и программисты явские в них обычно тоже плохо умеют. Возможно, в них умеют какие-нибудь дата саентисты - настоящие, а не на недельных курсах подготовленные.
> Я бы наоборот сказал: представление данных в ORM как раз таки и приближенно максимально к любимым высокоуровневыми программистами сущностям, которые в программе удобно передать по ссылке целиком и вызвать у них методы.
Оно общее для всей системы, поэтому с большой вероятностью не будет удобно ни для какой конкретной задачи, кроме примитивного CRUD'а.
> А в реляционку это потом упихивают ногами. А в произвольные проекции из произвольных джойнов для поиска по хитрым _взаимо_связям ORM умеет очень плохо, ну так и программисты явские в них обычно тоже плохо умеют.
Ага. Как правило, в результате получаются системы, которые укладываются под нагрузкой в продакшене. И джава программистам приходится учиться оптимизировать. Been there. Про то, что ORM скрывает от программиста возможности эффективной оптимизации, не скрывая при этом сложности нижележащей системы, я как раз и писал.
Если у нас стоит задача положить в БД сущности типа A, которые могут включать в себя (композиция) множественные сущности вида Б каждая, то задача "выгрузить множество А по такому-то критерию вместе с ихними Б" хорошего решения в один запрос в реляционной модели не имеет (кроме разве что случая сильно не атомарных типов столбцов, а то и вовсе JSON БД). Надо или делать аццкий джойн, который вернёт поля типа А по много раз (можно аццкую денормализацию, но суть будет та же), или делать два запроса (сначала А, потом Б по известным айдишкам из первого запроса)
Comments 8
Я бы наоборот сказал: представление данных в ORM как раз таки и приближенно максимально к любимым высокоуровневыми программистами сущностям, которые в программе удобно передать по ссылке целиком и вызвать у них методы. И связаны эти сущности в иерархические деревья с чёткой принадлежностью детей родителям. А в реляционку это потом упихивают ногами. А в произвольные проекции из произвольных джойнов для поиска по хитрым _взаимо_связям ORM умеет очень плохо, ну так и программисты явские в них обычно тоже плохо умеют. Возможно, в них умеют какие-нибудь дата саентисты - настоящие, а не на недельных курсах подготовленные.
Reply
Оно общее для всей системы, поэтому с большой вероятностью не будет удобно ни для какой конкретной задачи, кроме примитивного CRUD'а.
> А в реляционку это потом упихивают ногами. А в произвольные проекции из произвольных джойнов для поиска по хитрым _взаимо_связям ORM умеет очень плохо, ну так и программисты явские в них обычно тоже плохо умеют.
Ага. Как правило, в результате получаются системы, которые укладываются под нагрузкой в продакшене. И джава программистам приходится учиться оптимизировать. Been there. Про то, что ORM скрывает от программиста возможности эффективной оптимизации, не скрывая при этом сложности нижележащей системы, я как раз и писал.
Reply
Reply
Reply
Leave a comment