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