Я чувствовал, что что-то с этими ORM не так, но не мог сказать словами, теперь заинтересовался и обязательно буду гуглить дальше, но пожалуйста пожалуйста пожалуйста сделайте полноценный доклад об этом, вот чтобы комплексно, как вы умеете
Обязательно сделаю, это просто очень большая работа, чтобы запихнуть сотни проблем в 30-40 минут, это нужно их сгруппировать, выделить самое важное, проиллюстрировать хорошими примерами, а это я так, только две проблемы полчаса рассказывал )))
Всё можно было сказать гораздо короче: "ORM не позволяет использовать дополнительные возможности СУБД" И всё сказано, в принципе, правильно, пока не потребуется внести изменения в модель - вот тут то и начнутся танцы, которые ORM автоматизировала бы сама (с SQL, согласованием полей, поиском по десятку файлов и т.д. и т.п.)
Тимур рассуждает о том, что ОРМ зло, в комплекте с моделированием предметной области посредством ООП (domain model, active record, rich object). Приходит к выводу, что если делать доменную модель в тех случаях, когда предметная область уже не предметная область (модель на модель), то будут проблемы (выгрузка объектов в память, агрегация в памяти и т.п.). Т.е. по сути, претензии не к ОРМ, а к доменной модели в случаях, когда лучше обойтись без неё.
Разве кто-то использует орм чтоб вертеть миллион записей в оперативе? Гидратация убьет весь перформанс и подкинет проблем с памятью. Но если вас устраивает пагинация и батчинг, то никакой проблемы нет. Весь доклад Тимура сводится к фразе "знайте свои инструменты и пользуйтесь ими правильно".
@@TimurShemsedinov релиз версии Bun 1.0 состоялся почти месяц назад и за сентябрь ему добавили почти 20к звёзд на Гитхабе. Bun явно заслуживает внимания и интересно понаблюдать за его развитием. На данный момент он пока сыроват для продакшена, но, думаю, что в 2024 году многие новые проекты будут запускаться на нём вместо NodeJS или Deno
Не обязательно, если есть в проекте ORM, в каждом месте ее использовать. Многие ORM пакеты предоставляют Query Builder или возможность выполнить сырой SQL. На мой взгляд, ORM - это хорошо, потому что в большинстве случаев обычной веб разработки ускоряет процесс написания приложения. А какие-то узкие места производительности, какие-то особые кейсы, можно покрывать QB, сырыми запросами, view и всякими пакетами в БД без проблем. Надо использовать преимущества каждого подхода, а не строго отказываться, потому что есть минусы.
Вот вообще ничего не ускоряется, без SQL кода больше и он в неестественном для баз виде. Писать запросы на JavaScript просто потому, что не можете освоить простой SQL, который можно базово понять за неделю...
@@TimurShemsedinovхм, мой опыт отличается получается. В моем опыте наоборот кода становилось меньше, а зачастую ORM под собой использовали в выходном запросе такие оптимизации, о которых и многие мидлы не догадываются. И с оптимизацией SQL может стать ещё более многословный. Но и были случаи, когда операция была слишком нетривиальной и с ORM описывать ее было нереально, но такое было очень редко по сравнению с большинством базовых операций и решалось возможностью исполнить сырой SQL.
Прятать бизнес логику в БД плохой тон. Например потому что их сложно дебажить. Поставить брейкпоинт в коде и посмотреть что там в рантайме - бесценно. Вычисляемые поля в ОРМ беда, но это выбор каждого. Можно в проекте запретить все вычисляемые поля, а вызывать методы расчета в классах обертках, которые и отвечают за роль (actor) кто запрашивет эти данные. В этом случае тестировать просто. Принцип "разделяй и властвуй" отработает и в случае внесения изменений не позволит "случайно" сломать код. А лучше пишите тесты и проверяйте всё. Большая часть ошибок из-за лени или тесно сжатых сроков и никакая бизнес логика в БД не спасет.
Бизнес-процессы нужно описывать в коде, а та логика, которая связана с данными и их консистентностью должна однозначно быть в базе, например каскадное удаление или запрет на удаление связанных записей вы тоже будете в коде писать? Вот так люди и доходят до джоинов в оперативке, прямо циклами и пишут, все в память подымают. А в больших организациях к базе ходят десятки приложений, и в каждом логику данных дублировать и потом кто-то немного не так ее реализовал и у всех рассыпалось? У меня 28 лет опыта и управление ИТ инфраструктурой из сотен информационных систем и с базами данных из тысяч таблиц и десятков терабайт реляционных данных, так что не вам мне рассказывать, как жить )))
@@TimurShemsedinovкакая-то логика определено должна быть в базе, например, приведённая в ваших примерах. Но я сталкивался с такими проектами, у которых в базе были сотни пакетов PL/SQL, которые нереально дорого было поддерживать, а с потерей специалистов, что этим занимались, произошла бы катастрофа. При этом, не было такого, что схемой пользовались разные проекты, для каждого была своя база. Это действительно страшно. Думаю тут должен быть баланс и отталкиваться нужно от конкретной ситуации и вводных, а не всегда делать каким-то одним образом.
Как будто в случае без орм не нужно вычислять высисляемые поля. Это будет делаться или в базе, или а запросе или в коде. Так примените эти же техники к орм! Загрузить миллион записей в оперативную память - это настолько редкий кейс. Тут пишется отдельный обработчик данных. Странно предлагать тут использовать орм, зная о гидратации. Если есть пагинация, скролл или батчинг. То проблем с орм не будет.
Опять готов подписаться под всем сказанным. Я обычно формулирую это так: "языки программирования приходят и уходят, а данные в БД - остаются, данные - они вечные. Все эти ORM окажутся там же, где COBOL, скорее всего ещё при моей жизни, и уж точно при вашей. А вот про SQL я этого сказать не могу." Но, конечно, доказывать это современным программистам крайне сложно, и утомительно. Время нас, конечно, рассудит, вот только.. те системы, которые были спроектированы написаны с использованием ORM, и которые выживут, всё равно кому-то надо будет поддерживать.. брр.. ;) P.S. заметки на полях, для алгоритмов.
Это все зависит от того, какой инструмент вы используете. Писать миграцию руками можно, но сложно, проще ее генерировать и потом при необходимости подправить. Конечно нужно иметь два варианта up и down, т.е. обычно и откат заготавливают, но это не всегда возможно. Лучше хранить схемы для каждой версии + 2 миграции, вверх и вниз. Хранить как .sql файлы, в имени миграций версию и дату лучше иметь, чтобы найти потом
Ну... я думаю, что все сказанные примеры описывают варианты как не нужно работать с ORM. То, что может сделать БД - должна делать БД, а не ORM. Да, ORM дает вам больше возможностей напортачить, но если вы инженер, то вы нормально напишите как с ORM, так и без нее. Просто ORM инженеру даст удобный инструмент и сократит кол-во бойлер-плейта, а кодеру - геморрой. Очень сильно ORM помогает при разработке микросервисов. Там нет 10 джойнов, максимум 2-3. Но скорость разработки больше, а кода меньше.
А что мешает при использовании ОРМ добавить мету к каждому полю и использовать для "проекций"? Денормализация - это норма. Вместо наследования можно использовать композицию. Тут поблема не с ORM и OOP. А в способах применения.
В базе эти операции будут на несколько порядков оптимальнее реализованы, так что, переносить что менять малый кусок ресурсов сервера бд на огромный кусок ресурсов сервера - это не оптимизация.
В EF.core есть такая штука как IQueriable, когда мы пишем ОРМский код он не выполняеться сразу а работает как кверибилдер, и в любой удобный момент можно его выполнить и продолжить работать уже как с коллекцией данных в оперативке, то есть там совмещаются два подхода, Query builder и обычный ORMвский, и переход между ними практически не заметный, как вам?
меня смущает, что код проще тестировать, чем эти процедурки в sql. потом, еще на уровне приложения нужно отвалидировать то, что к тебе приходит из твоей же базы.
На мой взгляд, валидировать базу данных на уровне приложения - это плохая идея. Логика в базе должна быть либо настолько простой, чтобы не требовать тестирования, либо тестироваться на уровне базы.
Я чувствовал, что что-то с этими ORM не так, но не мог сказать словами, теперь заинтересовался и обязательно буду гуглить дальше, но пожалуйста пожалуйста пожалуйста сделайте полноценный доклад об этом, вот чтобы комплексно, как вы умеете
Обязательно сделаю, это просто очень большая работа, чтобы запихнуть сотни проблем в 30-40 минут, это нужно их сгруппировать, выделить самое важное, проиллюстрировать хорошими примерами, а это я так, только две проблемы полчаса рассказывал )))
Тимур, вы хороший 😊😇
Всё можно было сказать гораздо короче: "ORM не позволяет использовать дополнительные возможности СУБД"
И всё сказано, в принципе, правильно, пока не потребуется внести изменения в модель - вот тут то и начнутся танцы, которые ORM автоматизировала бы сама (с SQL, согласованием полей, поиском по десятку файлов и т.д. и т.п.)
Мне кажется проблема не в самом ORM, а втом что люди пытаются на ее базе писать что-то помимо сериализации данных.
Зачем для такой простой задачи целая ОРМ?
Тимур рассуждает о том, что ОРМ зло, в комплекте с моделированием предметной области посредством ООП (domain model, active record, rich object).
Приходит к выводу, что если делать доменную модель в тех случаях, когда предметная область уже не предметная область (модель на модель), то будут проблемы (выгрузка объектов в память, агрегация в памяти и т.п.).
Т.е. по сути, претензии не к ОРМ, а к доменной модели в случаях, когда лучше обойтись без неё.
Разве кто-то использует орм чтоб вертеть миллион записей в оперативе? Гидратация убьет весь перформанс и подкинет проблем с памятью.
Но если вас устраивает пагинация и батчинг, то никакой проблемы нет.
Весь доклад Тимура сводится к фразе "знайте свои инструменты и пользуйтесь ими правильно".
Спасибо за контент! Планируете видео с обзором на Bun, который позиционируется как drop-in replacement for Node.js?
Да вы шо, первый раз слышу
@@TimurShemsedinov релиз версии Bun 1.0 состоялся почти месяц назад и за сентябрь ему добавили почти 20к звёзд на Гитхабе. Bun явно заслуживает внимания и интересно понаблюдать за его развитием. На данный момент он пока сыроват для продакшена, но, думаю, что в 2024 году многие новые проекты будут запускаться на нём вместо NodeJS или Deno
а процедуры и триггеры это легаси или нет? писать их на стороне sql или нет сейчас?
Писать, это ок
Не обязательно, если есть в проекте ORM, в каждом месте ее использовать. Многие ORM пакеты предоставляют Query Builder или возможность выполнить сырой SQL.
На мой взгляд, ORM - это хорошо, потому что в большинстве случаев обычной веб разработки ускоряет процесс написания приложения. А какие-то узкие места производительности, какие-то особые кейсы, можно покрывать QB, сырыми запросами, view и всякими пакетами в БД без проблем. Надо использовать преимущества каждого подхода, а не строго отказываться, потому что есть минусы.
Вот вообще ничего не ускоряется, без SQL кода больше и он в неестественном для баз виде. Писать запросы на JavaScript просто потому, что не можете освоить простой SQL, который можно базово понять за неделю...
@@TimurShemsedinovхм, мой опыт отличается получается. В моем опыте наоборот кода становилось меньше, а зачастую ORM под собой использовали в выходном запросе такие оптимизации, о которых и многие мидлы не догадываются. И с оптимизацией SQL может стать ещё более многословный. Но и были случаи, когда операция была слишком нетривиальной и с ORM описывать ее было нереально, но такое было очень редко по сравнению с большинством базовых операций и решалось возможностью исполнить сырой SQL.
@@TimurShemsedinov просто люди хотят развиваться, а не старперить)
@@romanmorgunov3438цікаво буде почитати хоча б про один кейс оптимізацій від ORM, бо зазвичай все навпаки і ORM притуляє зайвого
ОРМ робить код більш чистим і зрозумілим в більшості випадків
Очень нужен семинарчик или семинар или семинарище даже
Сделаем и доклад и семинар
Прятать бизнес логику в БД плохой тон. Например потому что их сложно дебажить. Поставить брейкпоинт в коде и посмотреть что там в рантайме - бесценно. Вычисляемые поля в ОРМ беда, но это выбор каждого.
Можно в проекте запретить все вычисляемые поля, а вызывать методы расчета в классах обертках, которые и отвечают за роль (actor) кто запрашивет эти данные. В этом случае тестировать просто. Принцип "разделяй и властвуй" отработает и в случае внесения изменений не позволит "случайно" сломать код.
А лучше пишите тесты и проверяйте всё. Большая часть ошибок из-за лени или тесно сжатых сроков и никакая бизнес логика в БД не спасет.
Бизнес-процессы нужно описывать в коде, а та логика, которая связана с данными и их консистентностью должна однозначно быть в базе, например каскадное удаление или запрет на удаление связанных записей вы тоже будете в коде писать? Вот так люди и доходят до джоинов в оперативке, прямо циклами и пишут, все в память подымают. А в больших организациях к базе ходят десятки приложений, и в каждом логику данных дублировать и потом кто-то немного не так ее реализовал и у всех рассыпалось? У меня 28 лет опыта и управление ИТ инфраструктурой из сотен информационных систем и с базами данных из тысяч таблиц и десятков терабайт реляционных данных, так что не вам мне рассказывать, как жить )))
@@TimurShemsedinovкакая-то логика определено должна быть в базе, например, приведённая в ваших примерах. Но я сталкивался с такими проектами, у которых в базе были сотни пакетов PL/SQL, которые нереально дорого было поддерживать, а с потерей специалистов, что этим занимались, произошла бы катастрофа. При этом, не было такого, что схемой пользовались разные проекты, для каждого была своя база. Это действительно страшно. Думаю тут должен быть баланс и отталкиваться нужно от конкретной ситуации и вводных, а не всегда делать каким-то одним образом.
@@romanmorgunov3438Не вижу противоречия. Логика данных в базе - это хорошо. Логика приложения в базе - это плохо
Как будто в случае без орм не нужно вычислять высисляемые поля. Это будет делаться или в базе, или а запросе или в коде. Так примените эти же техники к орм!
Загрузить миллион записей в оперативную память - это настолько редкий кейс. Тут пишется отдельный обработчик данных. Странно предлагать тут использовать орм, зная о гидратации.
Если есть пагинация, скролл или батчинг. То проблем с орм не будет.
Опять готов подписаться под всем сказанным.
Я обычно формулирую это так: "языки программирования приходят и уходят, а данные в БД - остаются, данные - они вечные. Все эти ORM окажутся там же, где COBOL, скорее всего ещё при моей жизни, и уж точно при вашей. А вот про SQL я этого сказать не могу."
Но, конечно, доказывать это современным программистам крайне сложно, и утомительно. Время нас, конечно, рассудит, вот только.. те системы, которые были спроектированы написаны с использованием ORM, и которые выживут, всё равно кому-то надо будет поддерживать.. брр.. ;)
P.S. заметки на полях, для алгоритмов.
Не будет ORM, будет что-то другое. Декларативный подход в целом останется и будет совершенствоваться дальше
вот с примером склада или бухгалтерией и ORM стало как-то понятнее
А как организовать работу с миграциями грамотно?
Это все зависит от того, какой инструмент вы используете. Писать миграцию руками можно, но сложно, проще ее генерировать и потом при необходимости подправить. Конечно нужно иметь два варианта up и down, т.е. обычно и откат заготавливают, но это не всегда возможно. Лучше хранить схемы для каждой версии + 2 миграции, вверх и вниз. Хранить как .sql файлы, в имени миграций версию и дату лучше иметь, чтобы найти потом
Краткий пересказ видео - я не умею пользоваться ОРМ, значит и вы тоже😅
Будь мужиком! Пиши запити до бази даних на сирому SQL! 💪
query-builder на подобии knex , зло ?
Разве что для простых случаев ок, а так только sql
Ну... я думаю, что все сказанные примеры описывают варианты как не нужно работать с ORM.
То, что может сделать БД - должна делать БД, а не ORM. Да, ORM дает вам больше возможностей напортачить, но если вы инженер, то вы нормально напишите как с ORM, так и без нее. Просто ORM инженеру даст удобный инструмент и сократит кол-во бойлер-плейта, а кодеру - геморрой.
Очень сильно ORM помогает при разработке микросервисов. Там нет 10 джойнов, максимум 2-3. Но скорость разработки больше, а кода меньше.
А что мешает при использовании ОРМ добавить мету к каждому полю и использовать для "проекций"? Денормализация - это норма. Вместо наследования можно использовать композицию.
Тут поблема не с ORM и OOP. А в способах применения.
Если послушать Тимура, то все зло, нужно назад к перфокартам возвращаться и не использовать ничего кроме 0 и 1 🤣
База масштабируется сильно сложнее чем стейтлес бекенд, если нет проблем с количеством данных на сети то лучше их обрабатывать на беке.
В базе эти операции будут на несколько порядков оптимальнее реализованы, так что, переносить что менять малый кусок ресурсов сервера бд на огромный кусок ресурсов сервера - это не оптимизация.
Я в отличи от Тимура могу себе позволить не корректность: то, что вы написали, это глупость несусветная
В EF.core есть такая штука как IQueriable, когда мы пишем ОРМский код он не выполняеться сразу а работает как кверибилдер, и в любой удобный момент можно его выполнить и продолжить работать уже как с коллекцией данных в оперативке, то есть там совмещаются два подхода, Query builder и обычный ORMвский, и переход между ними практически не заметный, как вам?
Та я писал на linq, это конкретно хорошая идея, но ef сам по себе ужасен
меня смущает, что код проще тестировать, чем эти процедурки в sql. потом, еще на уровне приложения нужно отвалидировать то, что к тебе приходит из твоей же базы.
На мой взгляд, валидировать базу данных на уровне приложения - это плохая идея. Логика в базе должна быть либо настолько простой, чтобы не требовать тестирования, либо тестироваться на уровне базы.