СХ
О каком сложном SQL что блять в нем сложного.
Современные ORM это про читаемость кода и удобство, а не про упрощение задачи.
Что на sqlalchemy намного проще писать запросы.
Аж пипец.
И не знаю из какого вы века, но современные ORM умеет и в индексы и джойны и ещё много чего.
Работают и с представлениями и с хранимыми процедурами.
И индексы и джойны это элементарные вещи которые должен знать и уметь бекенд программист любого уровня.
Независимо от того с SQL или с ORM.
А там где нужен прямо специфический запрос уже и пишут в raw c фильтрацией полей.
Если вы не умеете это нормально делать с ORM вы по умолчанию херовый программист.
И срезали себе ЗП да и рынку вы такой не нужен.
За проектирование и нормализацию отвечает сам программист.
Каким хером вы тут ORM приплели история умалчивает.
Если у вас дубликатов в базе 30% значит проектировал её дебил.
Есть и другая сторона монеты и другие дебилы.
А если у вас 1300 таблиц и пяти страничные запросы вы дебил который не умеет в ORM и денормализацию.
Ибо все хорошо в меру.
Современные ORM это про читаемость кода и удобство, а не про упрощение задачи.
Что на sqlalchemy намного проще писать запросы.
Аж пипец.
И не знаю из какого вы века, но современные ORM умеет и в индексы и джойны и ещё много чего.
Работают и с представлениями и с хранимыми процедурами.
И индексы и джойны это элементарные вещи которые должен знать и уметь бекенд программист любого уровня.
Независимо от того с SQL или с ORM.
А там где нужен прямо специфический запрос уже и пишут в raw c фильтрацией полей.
Если вы не умеете это нормально делать с ORM вы по умолчанию херовый программист.
И срезали себе ЗП да и рынку вы такой не нужен.
За проектирование и нормализацию отвечает сам программист.
Каким хером вы тут ORM приплели история умалчивает.
Если у вас дубликатов в базе 30% значит проектировал её дебил.
Есть и другая сторона монеты и другие дебилы.
А если у вас 1300 таблиц и пяти страничные запросы вы дебил который не умеет в ORM и денормализацию.
Ибо все хорошо в меру.
расскажу о 2 случаях, это были не наши кодеры, а мы принимали проекты\я работал в другой конторе.
1) у компании 2 базы, из одной данные льются во вторую, на первую забьём она не их по сути.
Во второй базе, открываю пг, вижу, 30 схем, иду дальше, одинаковые колонок, делаю селект, данные теже, иду к программистам мне в ответ
- у нас тупили селекты, мы юзаем орм, ничего умнее чем дублировать данные и добавлять схемы мы не придумали
говорю, ну надо сделать составные индексы, почистить бд от дубликатов, пройтись по запросам, посмотреть где пересечения индексов и сделать составные на необходимые запросы
- орм этого не умеет, делать ничего не будем...
занавес, продолжили пинять что пг не так настроен, а они няши.
2) решили что большой пг это плохо, тк запросы с орм выдавали инфу по 10 сек и более, о, у нас же микросервисы, и выдали каждому микросервису по своей базе, запрос который ранее делался через 1 бд, теперь делается вывозом 12 микросервисов, передаётся очередями к сервису выдачи. если сервису для выдачи результата нужно сделать несколько выборок мы получаем 24 сообщения в очереди, а при некоторых запросах даже бывало что информация просто терялась в этих бд, тк никто не понимал к какому микросервису обратиться за данными, но да, мы отказались от sql руками.
да, описано утрированно, там ещё редисы в промежутках между сервисами были и много ещё чего интересного придумано было, но суть ясна.
а если я видел базу больше 1 тб и орм, я сразу понимал, сервису чуть что будет плохо.
обижайся не обижайся, но я пока от использования орм в проекте видел для себя(девупса), только проблемы
1) у компании 2 базы, из одной данные льются во вторую, на первую забьём она не их по сути.
Во второй базе, открываю пг, вижу, 30 схем, иду дальше, одинаковые колонок, делаю селект, данные теже, иду к программистам мне в ответ
- у нас тупили селекты, мы юзаем орм, ничего умнее чем дублировать данные и добавлять схемы мы не придумали
говорю, ну надо сделать составные индексы, почистить бд от дубликатов, пройтись по запросам, посмотреть где пересечения индексов и сделать составные на необходимые запросы
- орм этого не умеет, делать ничего не будем...
занавес, продолжили пинять что пг не так настроен, а они няши.
2) решили что большой пг это плохо, тк запросы с орм выдавали инфу по 10 сек и более, о, у нас же микросервисы, и выдали каждому микросервису по своей базе, запрос который ранее делался через 1 бд, теперь делается вывозом 12 микросервисов, передаётся очередями к сервису выдачи. если сервису для выдачи результата нужно сделать несколько выборок мы получаем 24 сообщения в очереди, а при некоторых запросах даже бывало что информация просто терялась в этих бд, тк никто не понимал к какому микросервису обратиться за данными, но да, мы отказались от sql руками.
да, описано утрированно, там ещё редисы в промежутках между сервисами были и много ещё чего интересного придумано было, но суть ясна.
а если я видел базу больше 1 тб и орм, я сразу понимал, сервису чуть что будет плохо.
обижайся не обижайся, но я пока от использования орм в проекте видел для себя(девупса), только проблемы
