ясно, короче ненужная херня

просто в больших проектах ее не используют, прям в огромных

в чем профит, это тоже самое, только функциями

Не надо помнить названия классов и названия таблиц - достаточно только классов

это плюс кстати, да

а вот хуй

у меня всегда \dt открыта :)

когда хочется сделать обёртку вокруг пыховской базы, где префикс может быть произвольным, в орме это выливается в такую ёблю, что ну иво нахуй

а для оракла есть орм?

когда хочется сделать обёртку вокруг пыховской базы, где префикс может быть произвольным, в орме это выливается в такую ёблю, что ну иво нахуй

В алхимии? Есть средства для этого

ха

у меня тут есть несколько запросов в оракл на 3 А4 листа

В алхимии? Есть средства для этого

дерьмовые

интересно, кто-то юзает ли орм для таких запросов, лол

дерьмовые

Ээээ. __tablename__ кажется. В чем дерьмо?

Ээээ. __tablename__ кажется. В чем дерьмо?

это лишь очень малая часть

интересно, кто-то юзает ли орм для таких запросов, лол

Такой орм никто до сих пор не написал, просто. Потому что часов станет меньше

обычно с всякими жабовскими спрингами и гибернейтами

Такой орм никто до сих пор не написал, просто. Потому что часов станет меньше

каких еще часов?

бтв, есть ОРМы, которые умеют в оконные функции?

я кстати почему спросил, просто часто вижу в вакансиях, типа "умение работать с postgres БЕЗ ИСПОЛЬЗОВАНИЯ ОРМ"

лучше б спросил есть ли ормы, которые умеют в хранимые процедуры..

лучше б спросил есть ли ормы, которые умеют в хранимые процедуры..

не в питоне есть 100%

в питоне - хз

Отличное знание SQL, умение работать с базой напрямую без ORM;

вот например

https://spb.hh.ru/vacancy/17928908

Отличное знание SQL, умение работать с базой напрямую без ORM;

это означает, что у них нет DBA и человеку надо понимать, что такое селективность, как работают join и уметь пользоваться explain.

обычно, если человек работал с СУБД только через ОРМ, для него всё это тёмный лес

ну вот я про это и говорю

кстати, есть 4й плюс ОРМ. он может на клиенте посчитать, что в ответе на запрос будет 0 строк и не выполнять запрос в СУБД :)

Ну прям как дети малые. "ОРМ - говно, ОРМ - не нужно". А вы не подумали про то что все DB разные даже если у всех есть слово SQL? Оконные функции, процедуры вы говорите? Пишите это всё сами под свою любимую <DB_Name1>, в своём приватном репе и показывайте только избранным любителям <DB_Name1> , т.к. у остальных есть своя любимая <DB_Name2>, в которой ваши примочки просто не будут работать и потому им плевать на то, что ваша NoORM-либа супер быстрая и классная. Главный плюс "ОРМ" и разных SQL-врапперов в том, что они позволяют разработчикам библиотек не задумываться о тонкостях работы разных DB, а просто реализовывать функционал и быть увереным, что оно будет работать везде. Вот какой главный плюс джанги для многих? Куча готовых батареек под неё. А теперь представте, что часть этих батареек работает только под MySQL, другая только под PgSQL и ещё небольшая часть только под SQLite. Врятли такое дело бы понравилось кому то.

Орм это простота прототипирования приложения, теоретически меньше возможностей обосраться и работа с данными на уровне объектов того же питона. Тяжёлые запросы можно делать в plain sql

всё это красиво звучит, но вот добиться равной работы на разных субд весьма непросто, что с орм, что без

а ещё не надо помнить синтаскис join, group by, having, etc

Хуле там помнить

Ну прям как дети малые. "ОРМ - говно, ОРМ - не нужно". А вы не подумали про то что все DB разные даже если у всех есть слово SQL? Оконные функции, процедуры вы говорите? Пишите это всё сами под свою любимую <DB_Name1>, в своём приватном репе и показывайте только избранным любителям <DB_Name1> , т.к. у остальных есть своя любимая <DB_Name2>, в которой ваши примочки просто не будут работать и потому им плевать на то, что ваша NoORM-либа супер быстрая и классная. Главный плюс "ОРМ" и разных SQL-врапперов в том, что они позволяют разработчикам библиотек не задумываться о тонкостях работы разных DB, а просто реализовывать функционал и быть увереным, что оно будет работать везде. Вот какой главный плюс джанги для многих? Куча готовых батареек под неё. А теперь представте, что часть этих батареек работает только под MySQL, другая только под PgSQL и ещё небольшая часть только под SQLite. Врятли такое дело бы понравилось кому то.

смена субд в одном проекте - это настолько редкий и маловероятный случай, что это не плюс вообще.

а все эти штуки, которые начинают генерировать за меня запросы - не нужны.

Они не за тебя генерят. А генерят то что ты им сказал генерить

ну и да, добиться нормальной работы даже без орм сложно.

Они не за тебя генерят. А генерят то что ты им сказал генерить

"нет, ты сказал не А. ты сказал А".

смена субд в одном проекте - это настолько редкий и маловероятный случай, что это не плюс вообще.

а если мыслить не проектами, а продуктами?

а если мыслить не проектами, а продуктами?

если мыслить продуктами уровня Drupal, который ты продаёшь, то аналогично. я делал коробку на продажу, мы смену БД не давали сделать и очень быстро работали на выбранной нами.

Если ты обосрался в синтаксисе орма, то причём тут Орм?

если мыслить продуктами уровня Drupal, который ты продаёшь, то аналогично. я делал коробку на продажу, мы смену БД не давали сделать и очень быстро работали на выбранной нами.

ты ща какую-то хуйню ляпнул

ты ща какую-то хуйню ляпнул

наверно да. мы делали продукт. он работал с одной строго выбранной СУБД. ОРМ не нужен.

если делать как делают всякие вордпрессы и прочие друпалы, типа "я умею и на sqlite, и на mysql" и гарантировать скорость работы, то я не знаю как это делать

и зачем.

Если ты обосрался в синтаксисе орма, то причём тут Орм?

если ты обосрался в синтаксисе sql, то причём тут sql?

Я правда никогда не использую генерацию таблиц в ормах. Только рефлексию

смена субд в одном проекте - это настолько редкий и маловероятный случай, что это не плюс вообще.

Я ничего не говорил про смену DB посреди жизни проекта. Я говорил про "батарейки", которые использует проект. И редкий разработчкик reusable библиотек одикаково хорошо будет тестировать работу свой либы с разными DB. А потому мы бы получили на выходе ситуацию, которая когда то была (может и сейчас есть) в Drupal - в документации заявлялась работа с MySQL и PgSQL, а по факту работало только под первую.

у нас с тобой просто разное понимание слова "будет работать везде".

если ты обосрался в синтаксисе sql, то причём тут sql?

Именно, Орм генерит ровно то что ты ему сказал. Если запрос говно то что с ормом, что без результат будет говно.

Именно, Орм генерит ровно то что ты ему сказал. Если запрос говно то что с ормом, что без результат будет говно.

я лучше автора ОРМ знаю, какой запрос мне нужен. а ОРМ генерит постоянно какую-то хуйню, просто из-за сверхуниверсальности.

Приведи пример

у меня NDA на большинство примеров конкретных. плюс, чатик по питону, ормы которого я не использовал.

у нас с тобой просто разное понимание слова "будет работать везде".

Если не выходить за границы ORM или SQL-враппера, то проблемы работы с разными DB - не головняк разработчика батарейки. Он может написать багрепорт разработчикам ORM, отправить PULL-request и они починят эту багу.

Каждый должен делать свою работу.

А то это выливается в "ну я толком не разбирался, так, потыкал и чо та говно какое-то полезло"

у меня NDA на большинство примеров конкретных. плюс, чатик по питону, ормы которого я не использовал.

Хули NDA в обезличеном запросе?

из того, что навскидку приходит в голову - мне надо прочесть не все поля из таблицы, мне надо вызвать функцию в условии для join и прочее.

Если не выходить за границы ORM или SQL-враппера, то проблемы работы с разными DB - не головняк разработчика батарейки. Он может написать багрепорт разработчикам ORM, отправить PULL-request и они починят эту багу.

это безусловно плюс и я с ним не спорил никогда. если то, что даёт ОРМ устраивает - вперёд и с песней. я не видел ни одного ОРМ, который бы устроил меня. вот и всё. поэтому, ОРМ не нужны, кроме мапперов результатов запроса, который написал я, на объектную модель.

Хули NDA в обезличеном запросе?

для этого надо в поезде с edge залезть на рабочую машину через впн, найти запрос и обезличить его. извини, не выйдет :)

ну и я напомню свой вопрос про оконные функции.

они в стандарте sql уже лет 10.

ну и я напомню свой вопрос про оконные функции.

Алхимия поддерживает

Ну никого полностью не устраивает универсальность. Потому как, что бы сделать универсальность приходится ограничиваться с одной стороны минимальным множеством возможностей разных DB, которые работыют одинаково, с другой стороны - не сильно перегружать API, иначе всё это превратится в плохо поддерживаемого монстра. Частные кейсы могут запилить те, кому они нужны. Тут наверное вполне подходит принцип Парето

они в стандарте sql уже лет 10.

А реализация этого стандарта есть во всех DB (даже в SQLite)?

Ну никого полностью не устраивает универсальность. Потому как, что бы сделать универсальность приходится ограничиваться с одной стороны минимальным множеством возможностей разных DB, которые работыют одинаково, с другой стороны - не сильно перегружать API, иначе всё это превратится в плохо поддерживаемого монстра. Частные кейсы могут запилить те, кому они нужны. Тут наверное вполне подходит принцип Парето

ты безусловно прав. только мне везёт (или нет) оказываться там, где ОРМы не пашут :)

Алхимия поддерживает

good to know, посмотрю. спасибо.

ERROR: S client not available

А реализация этого стандарта есть во всех DB (даже в SQLite)?

предположим, что мне неинтересны СУБД, которые умеют в sql и не умеют оконных функций.

ты безусловно прав. только мне везёт (или нет) оказываться там, где ОРМы не пашут :)

Ну да, есть такое - ты попал в 20% "неудачников"

ну и обычно сервер можно спросить что он там умеет и как-то юзеру передать. типа просишь оконную функцию на том, что её не умеет - получи ошибку

предположим, что мне неинтересны СУБД, которые умеют в sql и не умеют оконных функций.

Ну вот таких разработчиков к сожалению меньшинство, поэтому ОРМ и SQL-врапперы на них не расчитаны.

ну и обычно сервер можно спросить что он там умеет и как-то юзеру передать. типа просишь оконную функцию на том, что её не умеет - получи ошибку

И что в этом случае должне делать разработчик либы, например реализующей дерево в RDB? Он должен подумать над тем что тут будет ошибка и выполнить работу другими средствами? Мне кажется ему проще будет сразу всё сделать другими средствами, которые не юзают уникальный функционал пары DB. А когда будет популярность и много запросов в баг-трекере - он может быть добавит оптимизированый вариант, специально ради 1-2 баз.

зависит от целей разработчика либы, тебе не кажется?

например, я в своих полутора либах для дотнета ставлю во главу угла скорость работы и оптимизацию по памяти и жертвую широтой поддержки из-за этого

Поддерживать всё и вся в одиночку, слишком геройская цель, что бы многие стремились к ней

они, правда, не совсем ОРМ.

каких еще часов?

Человеческих, за которые деньги платят

Ну прям как дети малые. "ОРМ - говно, ОРМ - не нужно". А вы не подумали про то что все DB разные даже если у всех есть слово SQL? Оконные функции, процедуры вы говорите? Пишите это всё сами под свою любимую <DB_Name1>, в своём приватном репе и показывайте только избранным любителям <DB_Name1> , т.к. у остальных есть своя любимая <DB_Name2>, в которой ваши примочки просто не будут работать и потому им плевать на то, что ваша NoORM-либа супер быстрая и классная. Главный плюс "ОРМ" и разных SQL-врапперов в том, что они позволяют разработчикам библиотек не задумываться о тонкостях работы разных DB, а просто реализовывать функционал и быть увереным, что оно будет работать везде. Вот какой главный плюс джанги для многих? Куча готовых батареек под неё. А теперь представте, что часть этих батареек работает только под MySQL, другая только под PgSQL и ещё небольшая часть только под SQLite. Врятли такое дело бы понравилось кому то.

Часть батареек джанги работает только с постгре ?

смена субд в одном проекте - это настолько редкий и маловероятный случай, что это не плюс вообще.

Убер уже третий раз меняет, емнип

Убер уже третий раз меняет, емнип

вы говорите об этом так, как будто это что-то хорошее

ага, причем с постре на мускуль, прям ШОК

у меня NDA на большинство примеров конкретных. плюс, чатик по питону, ормы которого я не использовал.

Nda на скуль-запросы? Ну, поменяй имена таблиц ?

Каждый должен делать свою работу.

Это значит, что никто не будет делать ничего

ага, причем с постре на мускуль, прям ШОК

Они, вроде, уже обратно успели

вы говорите об этом так, как будто это что-то хорошее

Это нормально

Они, вроде, уже обратно успели

пруфы?

недавно вон запись про мускуль в докере

так что вряд ли

In this article, we take a look at Schemadock, Uber Engineering's tooling solution for managing our increasing number of MySQL clusters.

1 ноября

Это нормально

у плохого инженера - инструмент виноват

на фб посмотрите

так фб и убер 2 разные вещи

да, это два разных сервиса

или компании

там бабки разные

а что у фб за бд?

мускуль там

они на 3/4 (как минимум) на мускуле