AO
говорю как человек, которому пришлось свапать недавно. И было очень больно
Size: a a a
2018 December 26
Вт
а как тогда решаете проблему свапа БД
rm -rf ./project; mkdir project
AO
rm -rf ./project; mkdir project
OG
где пруфы?) кто мешает написать свой драйвер к орм?
пруфы, на самом деле, в самой идее орм. они генерируют запрос, опираясь на документоориентированную структуру данных в модельном слое. в итоге получаются запросы с неимоверным количеством джоинов. и, что хуже всего, их практически невозможно оптимизировать на больших проектах
OG
я в свое время сталкивался с ситуацией когда данные в модель джоинились по 35 (или около того) таблицам, объем возвращаемых данных по одному запросу превышал 10 гигабайт
AO
пруфы, на самом деле, в самой идее орм. они генерируют запрос, опираясь на документоориентированную структуру данных в модельном слое. в итоге получаются запросы с неимоверным количеством джоинов. и, что хуже всего, их практически невозможно оптимизировать на больших проектах
Ну у них же есть какой-то контроль, который дает сама ORM. Тот же fetch eager в doctrine например, чтоб не плодить 45к джоинов
AO
Хотя, справедливости ради, где-то видел график любви ORM. Где чем больше человек знает SQL, тем меньше любит ORM)
OG
Ну у них же есть какой-то контроль, который дает сама ORM. Тот же fetch eager в doctrine например, чтоб не плодить 45к джоинов
возможно мое sequelize-fu было недостаточно сильно, но я ничего такого не нашел конкретно в сиквелайзе
AO
возможно мое sequelize-fu было недостаточно сильно, но я ничего такого не нашел конкретно в сиквелайзе
Про сиквелайз не в курсе, второй день с ним работаю
Я о том, что этот контроль, дает сам продукт, в виде ОРМ. Т.е. странно говорить, что все продукты неоч, на основе одного
Я о том, что этот контроль, дает сам продукт, в виде ОРМ. Т.е. странно говорить, что все продукты неоч, на основе одного
AO
потому и вспомнил доктрину
OG
Хотя, справедливости ради, где-то видел график любви ORM. Где чем больше человек знает SQL, тем меньше любит ORM)
кстати соглашусь ) зачастую проще выучить один раз SQL чем каждый раз приноравливаться к новой ормке
хотя джависты да, как-то работают с орм и зачастую знают SQL очень так себе
хотя джависты да, как-то работают с орм и зачастую знают SQL очень так себе
AO
кстати соглашусь ) зачастую проще выучить один раз SQL чем каждый раз приноравливаться к новой ормке
хотя джависты да, как-то работают с орм и зачастую знают SQL очень так себе
хотя джависты да, как-то работают с орм и зачастую знают SQL очень так себе
Ну, пока не нужно думать, как переходить с одной бд на другую, то да, инлайн SQL это прекрасно)
AO
Вообщем, @tshemsedinov будем ждать доклад, по поводу "почему ORM зло" )
OG
Ну, пока не нужно думать, как переходить с одной бд на другую, то да, инлайн SQL это прекрасно)
тут иногда с одной версии ноды на другую мигрировать проблема, что уж про бд говорить )
Вт
ви щас серьезно
Вт
почему б на ассемблере не писать ведь компилятор все-равно в кашу скомпилит ваш код
AO
почему б на ассемблере не писать ведь компилятор все-равно в кашу скомпилит ваш код
меньше гибкости. Я так понимаю, тут речь о гибкости как раз.
Хотя я всё равно за ОРМки
Хотя я всё равно за ОРМки
AO
и она тоже от ОРМки зависит
Вт
орм не только для "на коленке", это нормально так экономит время и позволяет не менять контекст часто, что, доказано, самая затратная операция для погромиста
OG
почему б на ассемблере не писать ведь компилятор все-равно в кашу скомпилит ваш код
потому что смысла в этом немного. затраты времени на разработку несоизмеримо выше выигрыша во времени исполнения кода.
а с орм проблема в том, что кажущийся выигрыш во времени оборачивается невероятной головной болью и невероятными усилиями для поддержки
а с орм проблема в том, что кажущийся выигрыш во времени оборачивается невероятной головной болью и невероятными усилиями для поддержки