Пишу на го именно потому что здесь не принято тянуть странные проблемы на продакшн. Насколько же проще подддерживать код, когда в нем нет орм. Тоже раньше писал на питоне, много. Го как глоток свежего воздуха после питона.
А можно в описание к видео добавить ссылки на затронутые ORM из доклада, а то перематывать и искать нужный момент не удобно. И спасибо за данное видео.
Как хорошо, что у го есть своя идеология и люди, которые ее поддерживают и бьют по рукам новаторам. Вы хотите как в других языках, где ты нативный язык вообще можешь не знать, а должен знать десяток фреймворков и даже не понимаешь, что происходит, вокруг сплошная магия! Вам дали язык, он со всем справляется, практически, из коробки,если хочется добавить, то вот вам библиотеки) ну не нужно тянуть в него лишнее, орм и тд, и заставлять разработчика бороться и копаться в инструменте, а не в решении проблемы
Худшее что может сделать ORM - дать унифицированный доступ к любой БД. Звучит круто, а на деле просто отрезание всех уникальных фич ради которых и существуют разные БД.
@@ВладимирЛеденёв-э6г А у вас такое развлечение каждую неделю переходить на новую БД? Над большими проектами работали? Партиционирование таблиц использовали, к примеру?
Я занимаюсь разработкой CMS для игр. Таких как Lineage 2, Perfect World, World of Warcraft. Ее используют как правило администраторы фришард серверов. Так вот в чем дело. У одной игры, может быть несколько эмуляторов. Например Lineage 2, может иметь Java эмулятор который использует MySQL, а также может иметь PTS сервер, где в качестве базы данных используется MSQLServer. Мне как разработчику и нафиг не упали эти уникальные фишки. У меня один проект, который должен работать с SQLite, MySQL, MSQLServer и т.п. И свапать драйверы он должен на лету. Так как у одного проекта, могут быть одновременно запущены несколько разных эмуляторов, от разных команд, с разными версиями игры и т.п. И чем меньше подобных различий будет, тем проще будет мне. Объективно ли мое мнение - нет. Как и все другие)
В микросервисах базу не шарят между разными компонентами, которые делают разные команды. Поэтому зависимости проще отследить и меньше риски, чем в монолитной архитектуре, где поменяешь тип у колонки - и где-то неизвестно где отвалится
ORM нужно уметь пользоваться. Не заставляйте ORM делать джойны выгребая все сразу, а старайтесь делать одиночные запросы. Джойны и в чистом SQL будут тормозить. Если хорошо оптимизировать орм, то она может работать быстрее всяких связок db/sqlx.
В больших и сложных проектах где очень сложные сущности и взаимоотношения между данными базы без ORM не обойтись. ORM снижает производительность впринципе. Но, это меньшее зло по сравнению с тем, что могут натворить шаловливые ручки программистов имеющих произвольный доступ к таблицам базы данных. Типичный пример - богомерзкий 1С, поумолчанию использует ORМ, управлять базой из 1500(ERP среднего предприятия) таблиц имеющих сложные взаимосвязи практически нереально.
Да, ORM - это круто! В проекте Doctrine делала два запроса в одном 12 JOIN, второй 8 JOIN. Руками переписал на запрос с одним JOIN и второй запрос к одной таблице. Главное, что для всех это было сюрпризом. P.S. Меня брали как Go Developer, но потом заставили опуститься до PHP.
![[Live] ศึกมหึมันส์มวยไทยสังเวียนเดือด เวทีมวยชั่วคราวสวนสยาม | จันทร์ 30 กันยายน 2567](http://i.ytimg.com/vi/pM1k6f7JXUc/mqdefault.jpg)
![[UNCUT] “บอสณวัฒน์” ลากไส้!! ใครหนุนหลัง "แม่ตั๊ก ป๋าเบียร์" I คนดังนั่งเคลียร์ I 30 ก.ย. 67](http://i.ytimg.com/vi/QlD7mU2KKRk/mqdefault.jpg)
Пишу на го именно потому что здесь не принято тянуть странные проблемы на продакшн.
Насколько же проще подддерживать код, когда в нем нет орм.
Тоже раньше писал на питоне, много. Го как глоток свежего воздуха после питона.
Ясно=) Окей)
В сложных запросах мне проще написать без ORM
А можно в описание к видео добавить ссылки на затронутые ORM из доклада, а то перематывать и искать нужный момент не удобно.
И спасибо за данное видео.
Как хорошо, что у го есть своя идеология и люди, которые ее поддерживают и бьют по рукам новаторам. Вы хотите как в других языках, где ты нативный язык вообще можешь не знать, а должен знать десяток фреймворков и даже не понимаешь, что происходит, вокруг сплошная магия! Вам дали язык, он со всем справляется, практически, из коробки,если хочется добавить, то вот вам библиотеки) ну не нужно тянуть в него лишнее, орм и тд, и заставлять разработчика бороться и копаться в инструменте, а не в решении проблемы
Худшее что может сделать ORM - дать унифицированный доступ к любой БД. Звучит круто, а на деле просто отрезание всех уникальных фич ради которых и существуют разные БД.
Я только ради этого и использую ОРМ. Нафиг не нужны эти фичи, если они влияют на синтаксис SQL и с одной на другую базу нужно переписывать код.
@@ВладимирЛеденёв-э6г А у вас такое развлечение каждую неделю переходить на новую БД? Над большими проектами работали? Партиционирование таблиц использовали, к примеру?
Я занимаюсь разработкой CMS для игр. Таких как Lineage 2, Perfect World, World of Warcraft. Ее используют как правило администраторы фришард серверов. Так вот в чем дело. У одной игры, может быть несколько эмуляторов. Например Lineage 2, может иметь Java эмулятор который использует MySQL, а также может иметь PTS сервер, где в качестве базы данных используется MSQLServer. Мне как разработчику и нафиг не упали эти уникальные фишки. У меня один проект, который должен работать с SQLite, MySQL, MSQLServer и т.п. И свапать драйверы он должен на лету. Так как у одного проекта, могут быть одновременно запущены несколько разных эмуляторов, от разных команд, с разными версиями игры и т.п. И чем меньше подобных различий будет, тем проще будет мне. Объективно ли мое мнение - нет. Как и все другие)
Sqlc не упоминается
Видео старое, stable-версия sqlc вышла в 2020 только
Классный доклад
КГ\АМ
В микросервисах базу не шарят между разными компонентами, которые делают разные команды. Поэтому зависимости проще отследить и меньше риски, чем в монолитной архитектуре, где поменяешь тип у колонки - и где-то неизвестно где отвалится
если хотите ORM лучше не используйте SQL и всё.
Клево, спасибо за доклад)
ORM нужно уметь пользоваться. Не заставляйте ORM делать джойны выгребая все сразу, а старайтесь делать одиночные запросы. Джойны и в чистом SQL будут тормозить. Если хорошо оптимизировать орм, то она может работать быстрее всяких связок db/sqlx.
джоины в чистом скл тормозят только в слаборазвитых умах ормщиков.
Спасибо за доклад. было бы интересно узнать так же об prisma которая хорошо зарекомендовала себя в js, и добавляет поддержку golang
Prisma Client Go is no longer officially maintained.
Там ещё бекенд самой ормки на расте, что довольно интересно
В больших и сложных проектах где очень сложные сущности и взаимоотношения между данными базы без ORM не обойтись. ORM снижает производительность впринципе. Но, это меньшее зло по сравнению с тем, что могут натворить шаловливые ручки программистов имеющих произвольный доступ к таблицам базы данных. Типичный пример - богомерзкий 1С, поумолчанию использует ORМ, управлять базой из 1500(ERP среднего предприятия) таблиц имеющих сложные взаимосвязи практически нереально.
Да, ORM - это круто!
В проекте Doctrine делала два запроса в одном 12 JOIN, второй 8 JOIN.
Руками переписал на запрос с одним JOIN и второй запрос к одной таблице.
Главное, что для всех это было сюрпризом.
P.S. Меня брали как Go Developer, но потом заставили опуститься до PHP.
Бедная, аж до PHP опустили... А че согласилась тогда? Если это такое дно...