Пишу на го именно потому что здесь не принято тянуть странные проблемы на продакшн. Насколько же проще подддерживать код, когда в нем нет орм. Тоже раньше писал на питоне, много. Го как глоток свежего воздуха после питона.
Как хорошо, что у го есть своя идеология и люди, которые ее поддерживают и бьют по рукам новаторам. Вы хотите как в других языках, где ты нативный язык вообще можешь не знать, а должен знать десяток фреймворков и даже не понимаешь, что происходит, вокруг сплошная магия! Вам дали язык, он со всем справляется, практически, из коробки,если хочется добавить, то вот вам библиотеки) ну не нужно тянуть в него лишнее, орм и тд, и заставлять разработчика бороться и копаться в инструменте, а не в решении проблемы
Он не совсем справляется. Если бы он со всем справлялся, он был бы идеальным языком. А так он медленный. Python тоже якобы со всем справляется. Вопрос - как.
А можно в описание к видео добавить ссылки на затронутые 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 - это круто! В проекте Doctrine делала два запроса в одном 12 JOIN, второй 8 JOIN. Руками переписал на запрос с одним JOIN и второй запрос к одной таблице. Главное, что для всех это было сюрпризом. P.S. Меня брали как Go Developer, но потом заставили опуститься до PHP.
В больших и сложных проектах где очень сложные сущности и взаимоотношения между данными базы без ORM не обойтись. ORM снижает производительность впринципе. Но, это меньшее зло по сравнению с тем, что могут натворить шаловливые ручки программистов имеющих произвольный доступ к таблицам базы данных. Типичный пример - богомерзкий 1С, поумолчанию использует ORМ, управлять базой из 1500(ERP среднего предприятия) таблиц имеющих сложные взаимосвязи практически нереально.
Пишу на го именно потому что здесь не принято тянуть странные проблемы на продакшн.
Насколько же проще подддерживать код, когда в нем нет орм.
Тоже раньше писал на питоне, много. Го как глоток свежего воздуха после питона.
Ясно=) Окей)
Как хорошо, что у го есть своя идеология и люди, которые ее поддерживают и бьют по рукам новаторам. Вы хотите как в других языках, где ты нативный язык вообще можешь не знать, а должен знать десяток фреймворков и даже не понимаешь, что происходит, вокруг сплошная магия! Вам дали язык, он со всем справляется, практически, из коробки,если хочется добавить, то вот вам библиотеки) ну не нужно тянуть в него лишнее, орм и тд, и заставлять разработчика бороться и копаться в инструменте, а не в решении проблемы
Он не совсем справляется. Если бы он со всем справлялся, он был бы идеальным языком. А так он медленный. Python тоже якобы со всем справляется. Вопрос - как.
В сложных запросах мне проще написать без ORM
Классный доклад
А можно в описание к видео добавить ссылки на затронутые ORM из доклада, а то перематывать и искать нужный момент не удобно.
И спасибо за данное видео.
Клево, спасибо за доклад)
В микросервисах базу не шарят между разными компонентами, которые делают разные команды. Поэтому зависимости проще отследить и меньше риски, чем в монолитной архитектуре, где поменяешь тип у колонки - и где-то неизвестно где отвалится
так меняйте тип безопасно, не всем нужны микросервисы
@PanicWassano Конечно не всем. Я бы даже сказал что большинству не нужны
Худшее что может сделать 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 нужно уметь пользоваться. Не заставляйте ORM делать джойны выгребая все сразу, а старайтесь делать одиночные запросы. Джойны и в чистом SQL будут тормозить. Если хорошо оптимизировать орм, то она может работать быстрее всяких связок db/sqlx.
джоины в чистом скл тормозят только в слаборазвитых умах ормщиков.
если хотите ORM лучше не используйте SQL и всё.
Да, ORM - это круто!
В проекте Doctrine делала два запроса в одном 12 JOIN, второй 8 JOIN.
Руками переписал на запрос с одним JOIN и второй запрос к одной таблице.
Главное, что для всех это было сюрпризом.
P.S. Меня брали как Go Developer, но потом заставили опуститься до PHP.
Бедная, аж до PHP опустили... А че согласилась тогда? Если это такое дно...
Спасибо за доклад. было бы интересно узнать так же об prisma которая хорошо зарекомендовала себя в js, и добавляет поддержку golang
Prisma Client Go is no longer officially maintained.
Там ещё бекенд самой ормки на расте, что довольно интересно
КГ\АМ
В больших и сложных проектах где очень сложные сущности и взаимоотношения между данными базы без ORM не обойтись. ORM снижает производительность впринципе. Но, это меньшее зло по сравнению с тем, что могут натворить шаловливые ручки программистов имеющих произвольный доступ к таблицам базы данных. Типичный пример - богомерзкий 1С, поумолчанию использует ORМ, управлять базой из 1500(ERP среднего предприятия) таблиц имеющих сложные взаимосвязи практически нереально.