Возможно я вас не до конца понял, но мне кажется вы не правы.
Функция вполне себе может получать нечто, изменять это и возвращать наружу, собственно оно так обычно и происходит. Скатываться при этом до процедур обычно необходимости нет. Если же применительно к хранилищам, то там может быть что-то вроде такого: collection->get()->map()->save(); Собственно вроде как мы что-то поменяли, однако в целом все понятно.
>Это как вы такой вывод сделали?
Из сугубо практического опыта.
>В чем, по-вашему, принципиальное различие
Странный вопрос, ну банально же, sql это sql а orm нотация такая как захотите :D
>Емкость батареи 6600 мАч, заряжается 4 часа, хватает на 18 км пути.
Этот странный момент, когда понимаешь, что энергии в твоем телефоне хватает чтоб доехать от дома до работы.
>2015. Наши дни
Ого, ей еще кто-то пользуется.
Сам перешел на сторонние клиенты, которые не только аську поддерживали, где-то в 2006, где-то с 2010 уже как то никто номерами аськи не обменивался, а уже годиком позже список контаков аськи почти весь постоянно был офлайн.
>>Что пофиг для чего схему генерить для pg или mysql?
>Да
Тут надо было написать «спасибо кэп», но самое смешное, что если писать свою генерилку, то уже не так все однозначно.
>Doctrine умеет в монго и достаточно большой список реляционок.
Есть опыт на доктрине поднимать успешный проект где 500+ различных типов сущностей, между ними пара тысяч связей, при этом чтение/запись 50/50 и запросов к сущностям по десятку тысяч в секунду и более? Поделитесь, думаю будет многим интересно.
>Честно скажу, если не ужимается, то у вас что-то не так с формализацией.
С формализацией чего? бизнес процессов? В том то и дело, что в сложных случаях либо база красивая, но абстракции в коде не очень, либо абстракции годные, но в базе их сложно хранить и если в таких случаях использовать какой-то полу-универсальный ОРМ может начаться треш и угар.
>В том то и фишка, что как только все это вы начинаете учитывать,
>становится проще начать проектирование решения с базы данных :)
И у вас особенности базы данных начинают влиять на архитектуру проекта, далее на его бизнес процессы, а далее как часто бывает манагер слышит «ой блин, это нереально переделать»
>Типа зачем учить эту скучную теорию работы с РСУБД если можно взять и просто положить объект как он есть?
Чего там учить? Основ в виде тонкой книжки, которая читается за вечер хватает на 95%+ задач, давай те уж друг перед другом не будем выпендриваться тем как сложно жить программистам :)
>Это один из факторов.
ну так да, однако сначала вы сказали что «Из-за этого кстати был рост», слишком категорично вообщем
>Ровно до того момента, как вам потребуется построить аналитику или сделать отчеты.
Аналитика отчеты это статистика? Ну ее как бы и хранить нужно в каких-нить колоночных субд.
>Плюс очень часто встречаются ошибки при проектировании,
>а ошибиться там весьма просто и внезапно выбор NoSQL перестает вывозить.
Пример хоть приведите, а то както получается по вашим словам что в noSQL все так круто и нет ошибок которые потом оборачиваются принудительной эпиляцией разных частей тела. А вообще я не за noSQL, не надо меня убеждать что оно не очень, мне пофигу, юзаю когда считаю что подходит больше чем всякое другое.
>Если у вас получаются странные абстракции в коде, то вы явно как-то не так спроектировали БД.
Не всегда получается бизнес-процессы ужать в рамки БД, мир он как бы не идеальный. А проекты бывают еще и очень большими с точки зрения типов сущностей данных.
>Обычно получается не монструозная прокладка, а весьма тормозная схема, которую СУБД прожевывает с трудом.
Тормозная схема получается если тупить. Если же все делать учитывая возможности (особенности в целом уже мелочь) СУБД, ну хотя бы банально знать о том что такое индексы и знать что не все запросы одинаковы быстрые, то как раз, через учет этого прокладка в большом проекте может стать монструозной.
>Из-за этого кстати был рост популярности NoSQL решений. Там типа такой проблемы нет.
NoSQL они как бы разные бывают, я бы не стал так категорично решать что рост их популярности связан с этим.
Вот можно взять абстрактную задачу с системой, в которой есть множество документов, с различными наборами полей. Ее реально намного проще и дешевле реализовать, на Монго, чем например на MySql
Работал с ним немного, могу ошибаться, но временами оно неконтроллируемо порождает кучу неоправданных запросов. Также трудно прозрачно контролировать сами запросы на тему производительности.
>Напоминаю ORM является текущей абстракцией и стоит идти от меньшего к большему, а не наоборот.
>Да и по хорошему сначала проектируем БД, а уже потом делаем объекты.
Ну как бы что получается, у нас есть бизнес процессы, мы знаем какие для него нужны абстракции. Но. у нас есть база и у нее есть ограничение, поэтому мы пытаемся создать базу, ориентированную на бизнес, в результате получаем странные абстракции в коде.
С другой стороны можно создать годные абстракции в коде и подумать о их хранении позже, тогда получается некая монструозная прокладка, т.к. в классическую бд их просто так положить не получается.
Вот автор статьи и пишет в целом про то что ОРМ это какая-то хренотень в результате и что не надо парить мозг, все равно идеально не получится.
Статью еще не прочитали сразу в комментарии?)
>Сегодня мы публикуем перевод статьи, в которой Пиотр Солница, один из создателей популярного DataMapper для Ruby
Ну там и ссылка есть
Что вы имеете ввиду? Что пофиг для чего схему генерить для pg или mysql?
Или про то что у вас есть волшебная генерилка схем для любых объектов и для любых хранилищ?
Я написал «как вариант», суть в том что странно использовать навороченную бд и использовать 1% ее функционала, как обычно бывает в довольно большой части случаев, при этом писать прокладку, которая абстракции разворачивает в классические таблицы.
А что вам так Монга не нравится?)
Есть мнение, что если читать перевод чьей-то блогозаписи в переводе на другом ресурсе, не зная толком кто есть автор, то можно не понять над чем этот автор стебается.
> Функция же по определению ничего не меняет.
Как-то не сильно понятно, что вы этим сказать хотели. Функциональщики пишут проги которые могут только читать?
Если некто, возможно умный и популярный в некоторых кругах, написал хрень она от его умности и популярности менее хренью не станет.
Впрочем хрень тут вообщем-то в деталях и если некоторые термины заменить несколько другими, то смысл и эмоциональная составляющая поменяются.
Возможно не правильное понимание автора из-за перевода, похорошему надо бы почитать оригинал, ну тем кому еще не надоело решать надуманные проблемы.
Функция вполне себе может получать нечто, изменять это и возвращать наружу, собственно оно так обычно и происходит. Скатываться при этом до процедур обычно необходимости нет. Если же применительно к хранилищам, то там может быть что-то вроде такого: collection->get()->map()->save(); Собственно вроде как мы что-то поменяли, однако в целом все понятно.
Из сугубо практического опыта.
>В чем, по-вашему, принципиальное различие
Странный вопрос, ну банально же, sql это sql а orm нотация такая как захотите :D
>Я — один из этих «динозавров» :) Сидим с другом постоянно в аське…
Внезапно мы узнали не только количество, но даже узнали кто это :DDD
Этот странный момент, когда понимаешь, что энергии в твоем телефоне хватает чтоб доехать от дома до работы.
теперь чтобы уйти от скайпа:
Ого, ей еще кто-то пользуется.
Сам перешел на сторонние клиенты, которые не только аську поддерживали, где-то в 2006, где-то с 2010 уже как то никто номерами аськи не обменивался, а уже годиком позже список контаков аськи почти весь постоянно был офлайн.
>Да
Тут надо было написать «спасибо кэп», но самое смешное, что если писать свою генерилку, то уже не так все однозначно.
>Doctrine умеет в монго и достаточно большой список реляционок.
Есть опыт на доктрине поднимать успешный проект где 500+ различных типов сущностей, между ними пара тысяч связей, при этом чтение/запись 50/50 и запросов к сущностям по десятку тысяч в секунду и более? Поделитесь, думаю будет многим интересно.
С формализацией чего? бизнес процессов? В том то и дело, что в сложных случаях либо база красивая, но абстракции в коде не очень, либо абстракции годные, но в базе их сложно хранить и если в таких случаях использовать какой-то полу-универсальный ОРМ может начаться треш и угар.
>В том то и фишка, что как только все это вы начинаете учитывать,
>становится проще начать проектирование решения с базы данных :)
И у вас особенности базы данных начинают влиять на архитектуру проекта, далее на его бизнес процессы, а далее как часто бывает манагер слышит «ой блин, это нереально переделать»
>Типа зачем учить эту скучную теорию работы с РСУБД если можно взять и просто положить объект как он есть?
Чего там учить? Основ в виде тонкой книжки, которая читается за вечер хватает на 95%+ задач, давай те уж друг перед другом не будем выпендриваться тем как сложно жить программистам :)
>Это один из факторов.
ну так да, однако сначала вы сказали что «Из-за этого кстати был рост», слишком категорично вообщем
>Ровно до того момента, как вам потребуется построить аналитику или сделать отчеты.
Аналитика отчеты это статистика? Ну ее как бы и хранить нужно в каких-нить колоночных субд.
>Плюс очень часто встречаются ошибки при проектировании,
>а ошибиться там весьма просто и внезапно выбор NoSQL перестает вывозить.
Пример хоть приведите, а то както получается по вашим словам что в noSQL все так круто и нет ошибок которые потом оборачиваются принудительной эпиляцией разных частей тела. А вообще я не за noSQL, не надо меня убеждать что оно не очень, мне пофигу, юзаю когда считаю что подходит больше чем всякое другое.
Не всегда получается бизнес-процессы ужать в рамки БД, мир он как бы не идеальный. А проекты бывают еще и очень большими с точки зрения типов сущностей данных.
>Обычно получается не монструозная прокладка, а весьма тормозная схема, которую СУБД прожевывает с трудом.
Тормозная схема получается если тупить. Если же все делать учитывая возможности (особенности в целом уже мелочь) СУБД, ну хотя бы банально знать о том что такое индексы и знать что не все запросы одинаковы быстрые, то как раз, через учет этого прокладка в большом проекте может стать монструозной.
>Из-за этого кстати был рост популярности NoSQL решений. Там типа такой проблемы нет.
NoSQL они как бы разные бывают, я бы не стал так категорично решать что рост их популярности связан с этим.
Вот можно взять абстрактную задачу с системой, в которой есть множество документов, с различными наборами полей. Ее реально намного проще и дешевле реализовать, на Монго, чем например на MySql
>Да и по хорошему сначала проектируем БД, а уже потом делаем объекты.
Ну как бы что получается, у нас есть бизнес процессы, мы знаем какие для него нужны абстракции. Но. у нас есть база и у нее есть ограничение, поэтому мы пытаемся создать базу, ориентированную на бизнес, в результате получаем странные абстракции в коде.
С другой стороны можно создать годные абстракции в коде и подумать о их хранении позже, тогда получается некая монструозная прокладка, т.к. в классическую бд их просто так положить не получается.
Вот автор статьи и пишет в целом про то что ОРМ это какая-то хренотень в результате и что не надо парить мозг, все равно идеально не получится.
>Сегодня мы публикуем перевод статьи, в которой Пиотр Солница, один из создателей популярного DataMapper для Ruby
Ну там и ссылка есть
Или про то что у вас есть волшебная генерилка схем для любых объектов и для любых хранилищ?
А что вам так Монга не нравится?)
Как-то не сильно понятно, что вы этим сказать хотели. Функциональщики пишут проги которые могут только читать?
Впрочем хрень тут вообщем-то в деталях и если некоторые термины заменить несколько другими, то смысл и эмоциональная составляющая поменяются.
Возможно не правильное понимание автора из-за перевода, похорошему надо бы почитать оригинал, ну тем кому еще не надоело решать надуманные проблемы.