Я не буду учить твой Garbage Query Language

Original author: https://twitter.com/fulhack
  • Translation

Это будет немного напыщенная речь, но меня действительно раздражает софт, в котором люди пытаются изобрести очередной собственный язык запросов. У нас уже есть триллион различных ORM, еще триллион баз данных с собственным языком запросов каждая, и еще триллион SaaS-продуктов, для доступа к которым нужно освоить какой-нибудь очередной DSL, которые они придумали.


Верните мне мой SQL обратно. Это язык понятный каждому, существует аж с 70-х и за это время успел стать стандартом. Он прост в чтении и может использоваться кем угодно, от бизнеса до инженеров.


Однако вместо этого мне приходится изучать целый ворох разных "garbage query language", потому что люди по-прежнему пытаются изобрести колесо заново.


Начнем с ORM. Их основная фича — это сокращение времени разработки. Но вместо того, чтобы писать понятный всем SQL, мне приходится штудировать документацию конкретного ORM, чтобы выяснить, как писать для нее мои запросы. Кроме того, мне приходится тратить время на отладку, выяснять почему этот ORM перевел мой запрос в какой-то чудовищный SQL, который объединяет 17 таблиц, используя полное их сканирование. Вместо того, чтобы придерживаться стандартного SQL, где достаточно легко рассуждать об эффективности ("старайтесь использовать в предикатах индексированные столбцы", "не перебарщивайте с join'ами в одном запросе" и пр.), мне приходится иметь дело с дополнительным мутным слоем, который скрывает оригинальный SQL-запрос. В конечном итоге вы останетесь с распухшими классами данных более высокого уровня, вместо того чтобы иметь дело с простыми для понимания и обработки структурами БД.


Не говоря уже о том, что существует около пяти тысяч ORM, поэтому вместо изучения SQL один раз я должен изучить 34 разных ORM. Это не значит, что люди изучают ORM, это значит, что они просто не изучают SQL.


А еще все эти продукты SaaS. Я просто выбрал несколько из стека моей компании:


  • Splunk — SPL
  • Mixpanel — JQL
  • Rollbar — RQL
  • New Relic — NRQL
  • Adwords — AWQL

Что может быть хуже, чем свалка данных? Свалка данных, которая изобретает свой собственный язык запросов.


Справедливости ради следует сказать, что некоторые из таких запросов все-таки являются SQL-like или, по крайней мере, претендуют на эту роль, но с собственными причудами, которые заставляют меня отбросить все, что я знал о SQL ранее. Иногда до такой степени, что это эти прошлые знания могут оказаться практически бесполезными.


Кроме того, каждая база данных, также старается заново изобрести язык запросов. У Mongo есть свой ужасный язык запросов, который я никогда не понимал, у Lucene свой и т.д.


Что я прошу? На самом деле не много:


  1. Каждый SaaS-продукт должен предоставлять возможность скопировать все данные в мою собственную SQL БД (в моем случае Postgresql/Redshift). Я не хочу использовать их DSL. Возможно, Европейский союз сможет установить это в качестве следующего требования после принятия директивы по открытым банковским услугам PSD2.
  2. Необходим 30-летний мораторий на изобретение новых языков запросов.
  3. Нужно развеять миф о том, что ORM делают код чище. Переходите на сторону чистого SQL и вы получите гораздо более простое и прозрачное взаимодействие с вашей БД.

На этом все. Я понимаю, что похож на старого ворчуна, но я беру этот риск на себя.


PS


Этот пост получил достаточное количество просмотров, поэтому должен вызвать живой интерес среди публики. Следите за обсужденим на Hacker News и комментариями на Reddit r / programming.

Share post

Comments 259

    +4
    Да на здоровье. Пишите свой SQL, потом ещё SQL, который генерирует SQL и всю бизнес логику на SQL. И поддерживайте это всё, написать то ума много не надо.

    ORM дает общую обертку над кучей разных СУБД, у которых часто разный синтаксис, несмотря на SQL92 стандарт.
      +3

      Дело даже не в обертке — все равно большинство проектов использует на протяжении всей жизни одну и ту же СУБД — а в уменьшении количества разного рода boilerplate кода.


      С ORM код становится проще и понятнее, и поддерживает автоматические плюшки типа миграций и рефакторинга.


      Код с чистым SQL выглядит намного более громоздко (простыни SQL на десятки строк), понимается на самом деле сложнее (так как более многословен и часто требует дополнительных усилий по сериализации и десериализации данных).

        +18
        Если простыня SQL на десяток строк когда, то аналогичный код на ORM-обертках будем занимать на пару строчек меньше, но при этом без дебагера ты вряд ли узнаешь какой SQL он нагенерит.
          +6

          Как только вы напишите один и тот же sql запрос в 6 местах, а потом нужно будет его поменять, возможно, вам захочется вынести это в отдельный метод.


          А потом еще замапить данные на объект окажется неплохо.


          И вот у вас ORM.

            +18
            Как только вы напишите один и тот же sql запрос в 6 местах, а потом нужно будет его поменять, возможно, вам захочется вынести это в отдельный метод.

            Ну вы же не пишете один и тот же кусок кода в 6 разных местах. Зачем это делать с SQL?
              –9
              Ну, функцию я вызываю с разными параметрами. Сделать такое в sql из кода можно только с использованием храником, но боюсь бизнес-логика на базах данных это ад, который нельзя допускать в своем приложении по многим причинам.

              Значит вам надо выносить это в отдельную функцию, как я и описал.
                +5
                Запрос тоже можно вызывать с разными параметрами.
                  +2
                  В итоге в коде это все равно будет вынесено в отдельную функцию, я не прав? Или вы будете хранить параметризированный запрос в глобальной переменной?
                    +9
                    Разумеется это будет отдельная функция вы же этот запрос в 7 разных местах используете. Но что происходит в этой функции Вы знаете, и понимаете. А что там нагенерит ORM — бабка на двое сказала.
                      +4

                      Когда вас будет несколько — вы тоже не очень будете знать, какой же там запрос написал тот человек. Ну а необходимость залазить и смотреть, что же там написано приводит нас к такой же проблеме как ORM, в которой надо просто включить логгирование запросов.


                      В простых случаях и человек, и ORM ведут себя довольно предсказуемо, а вот как начинаются сложности, тут сложно сказать, что хуже, ORM или человек, который плохо пишет запросы.

                        +4
                        Не давайте писать запросы человеку который плохо их пишет.
                        В общем случае человек который плохо знает SQL и пишет его, лучше чем человек который плохо умеет ORM и пишет его.
                        Потому что проблема в SQL видна сразу, а проблема в ORM — нет.
                          0
                          Потому что проблема в SQL видна сразу, а проблема в ORM — нет.

                          select index, name, state from user_address where state like 'U%' and index >= 6


                          Подскажите тут проблему?


                          База пусть будет PostgreSQL.

                            +10
                            вариантов я вижу много, но ни одна из этих проблем не решается ORM-ом.
                            Кроме той что index возможно строка. Но это не проблема голый запрос просто упадет с ошибкой.
                            Проблема ORM в том, что он генерирует запрос который «вроде бы правильно работает». И в итоге нужно смотреть что же он там нагенерил и перепроверять.
                            Соответственно если я могу проверить корректность запроса — зачем мне ORM я и так могу написать нормально.
                            А если не могу — то давать мне ORM это почти тоже самое что давать обезьяне гранату.

                              –1

                              Если вы знаете как работает конкретный ORM — то в большинстве случаев не нужно. В крайних случаях приходится, но абсолютно так же надо будет смотреть что же там написал коллега.


                              Проблема сырых запросов в том, что ORM делает за вас очень много вещей для поддержки схемы данных и отображения ее структуры в коде. А так же ленивые выгрузки данных, кеширование, инструменты для пре- и пост-процессинга запросов и так далее.


                              Ну и так же, что вам все равно нужен минимальный ORM (который будет доставать результат из запроса и запихивать в объекты) для нормальной работы.


                              И если программисты, когда им нужно одно поле одной записи, вытаскивают из таблицы абсолютно все значения, они и с sql будут делать так же, если не хуже.

                                +13
                                Ну то есть мне нужно хорошо знать SQL и хорошо знать ORM. Такое себе если честно. Отсылка к коллеге это, мне кажется такой себе аргумент. Плохому программисту все-равно что портить SQL или ORM.

                                Автор же не имеет ничего против поддержки схемы, кэширование итд. Но ведь запросы можно же писать с использованием SQL. Не обязательно для этого новый язык придумывать.

                                Для задачи минимального маппинга есть Jdbc template.
                                Он делает ровно то что должен и ничего больше. Мапит result-set на объект.

                                Дело в том что ORM поощряет доставать всю таблицу чтобы получить одно значение, а SQL — нет.

                                  +2

                                  Мне кажется, вы говорите про какую-то конкретную ORM и распространяете ее проблемы на всех.


                                  Сначала конкретно про автора — он не шарит и применяет ту же логическую ошибку, что и по всей статье — у вас нет единого SQL. А значит вам все равно нужно изучить конкретную базу, что бы шарить с ее SQL диалектом, индексами, настройками и прочим.


                                  А после этого вам нужно будет искать инструмент, который позволит вам поддерживать схему базы данных в актуальном состоянии, распространять эту схему, версионировать, генерировать миграции. И разумеется, мапить на объекты. А значит держать схему в коде.


                                  Потом получится, что вместо того, что бы писать условный блок кода:


                                  with connection() as conn:
                                     query_raw_result = query.execute('select * from x where x.c > 5)
                                     record = mapping(query_raw_result)

                                  Вы напишите свою функцию и привяжите ее к классу, в который мапиться результат. Потом таких функций будет все больше и больше — и после рефакторинга вы получите легковестный orm способный на простые select/insert/update, а все остальное вы будете писать пока сырыми запросами. Ну и оно будет немного расширятся.


                                  Мне кажется, такой вариант вполне реальным, потому что я сам через такое прошел. ORM позволяет вместо изобретения своего велосипеда использовать стандартизированный.


                                  Дело в том что ORM поощряет доставать всю таблицу чтобы получить одно значение, а SQL — нет.

                                  Мне кажется, если у ORM отдельный метод на достать все и отдельный метод на фильтрацию — доставать все будет только оооочень плохой человек. А в sql можно просто where завтыкать написать и готово.

                                    +3
                                    Ничего что в вашем конкретном примере используется голый SQL? Более того конкретно этот пример будет нормально работает с любым ORM и его диалектом. А вы попробуйте написать запрос с 5ью джоинами и сложными условиями. Потом попробуйте повторить это на каком-нибудь hql или queryDsl. И не факт что с первого раза нормально получится.

                                    ORM это хорошо когда у вас простые однострочные запросы. ORM плохо когда надо через него генерить сложные вложенные запросы с аналитическими функциями. Вот где адок начинается.
                                      +1

                                      И в таких случаях используется или сырой SQL или же специальный класс, за которым скрывается view, который тоже написан на сыром SQL.


                                      И лично я не вижу в этом проблемы. ORM для рутинных запросов, сложные запросы на сыром SQL.


                                      Если вы используете ORM, у вас нет обязанности вот прямо все запросы писать на ORM, но большинство запросов, которые будут обычные select с парой фильтром или же insert вполне можно отдать ORM.

                                        +1
                                        А для простых запросов не нужен свой язык запросов. Он точно так же может работать на SQL. Все что нужно от ORM — использовать нативный SQL и нормально мапить result-set на объекты.
                                          0

                                          Как вы представляете использование сырого SQL на языках программирования, в которые они не встроены?


                                          То есть, вместо условного T1.objects.filter(pub_date__lte=5) мне стоит написать сырой sql запрос? Довольно много лишнего кода получится.


                                          Плюс я еще могу писать что-то в духе T1.expired() как алиас для запроса.


                                          Опять же таки, а как решить вопрос поддержки схемы базы данных, которая должна хранится в коде? Хранить схему в базе это полный треш, а отдельно от проекта мне кажется, не имеет смысла.

                                            +2
                                            Про другие языки я говорить не буду.
                                            Но если вы все-равно мапите результаты запроса на ваши доменные объекты, то проверить соответствие этих доменных объектов структуре базы не представляется сложным. Можно даже использовать стандартные аннотации.
                                            P.S. Все что я говорю относится к Java.
                                              0

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


                                              Поэтому обычно предпочитают вариант, когда используется code-first и схема базы управляется непосредственно из кода.


                                              То есть вам все равно нужен ORM, пусть и без возможности составления запросов.

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


                                                Отнюдь — habr.com/post/413597
                                                  0
                                                  Это ваши java/hibernate проблемы, правда. У нас вот на python/django таких проблем нет и пишутся модельки прямо из кода, потом создаются миграции и все это чудо няшно работает.

                                                  Ну и может я читал плохо, но я так и не нашел инструмента, который вы предлагаете использовать, что бы синхронизировать схемы базы на разных окружениях. Если этот инструмент «sql-скрипт» или «админ», то вас ждет очень много боли.
                                                    +6
                                                    Это ваши java/hibernate проблемы, правда. У нас вот на python/django таких проблем нет и пишутся модельки прямо из кода, потом создаются миграции и все это чудо няшно работает.
                                                    А вы внимательно прочитали статью? Там вообще-то универсальные проблемы. Создаст ли ваш мигратор индексы? А в нужном порядке? А все ли он правильно сделает? А не снесет ли случайно колонку с данными? На проде между прочим. Поэтому тут я согласен, мигрировать базу можно только чистым SQL и никак иначе. В противном случае на то, чтобы проверить что мигратор реально ничего не поломал вы потратите раз так в 5 больше времени чем на написание честного SQL обновления.
                                                      0

                                                      Отбросив вопрос про "все ли он правильно сделает", который применим в целом в sql скрипту в том числе, могу ответить одной фразой — "там прямо написано".


                                                      Миграции выглядят как-то так и все, что они сделают, в них написано. Поэтому проблема в том "а не сломает ли нам что-то мигратор" у нас обычно не стоит.


                                                      А в дополнение к этому еще можно вести версионность и зависимость между миграциями.


                                                      Ну и да, я имел дело с миграциями на чистом языке запросов и это всегда очень классно, потому что нужно самому отслеживать состояние схемы и угадывать, что уже было накачено, а что только нужно накатить.

                                                        +2
                                                        потому что нужно самому отслеживать состояние схемы и угадывать, что уже было накачено, а что только нужно накатить.

                                                        Зачем есть же тонна инструментов для этого. Тот же flyway.
                                                          0
                                                          Конкретно для той базы не было, к сожалению.

                                                            0
                                                            Это что за база такая? Flyway умеет всё что умеет JDBC.
                                                              0

                                                              Это была кассандра и миграции на CQL. Для реляционных мы используем django orm и там это решается на его уровне.


                                                              Касательно flyway — он классный. но вряд ли есть смысл заменять то, что используется сейчас на него и pure sql, если у нас нет проблем, описанный в статье.

                                                  0
                                                  Если я вас правильно понимаю, то вы предлагаете подход database-first, когда база данных служит источником схемы. По идее, это очень трешовый подход связанный с большим количеством проблем и рассинхронизации.
                                                  Что делать если новый код мы написали и развернули, а миграцию должны выкатить позже?
                                                    +1

                                                    Вы написали код, который использует новое поле, но миграцию для него, которая добавит поле в таблицу не сгенерировали или что вы имеете в виду?

                                                      0
                                                      Как в ORM с миграциями когда надо добавить новую колонку, а заполнять надо данными из другой таблицы, и этот запрос может занимать часы?
                                                        +1

                                                        Ну, миграции вы накатываете отдельной командой. Так что прямо во время запуска приложения всей кучей они не ломятся.

                                                          0
                                                          Ок, а как быть с
                                                          Как в ORM с миграциями когда надо добавить новую колонку, а заполнять надо данными из другой таблицы
                                                          ?
                                                            0

                                                            А в чем проблема, опять же? У вас на выбор будет:


                                                            • ДЛС для миграций
                                                            • Сырые sql скрипты
                                                            • Сырые скрипты на языке
                                                            • Расчетные поля, которые рассчитываются в тот момент, в какой вы достаете модель кодом и сохраняются.
                                                      0

                                                      Лишить премии? Новая функция не будет работать, если нет данных. Если у вас в коде IF, который фактически отключает эту новую функцию, то можно было и не выкладывать.


                                                      По уму нужно сначала миграции, потом код.

                                                      +1
                                                      Вот уж не знаю от кто тут трешевый, но для меня code-first делает видимую легкость написания приложения, где-то первые две недели. Если вы не заморачиваетесь перформансом то и первый год. Потом продакшин и жестокая реальность — так базы данных не проектируют.

                                                      В нашем ORM есть случи когда пользователь создает тикеты на микрооптимизации то на параметр, то на использование той или другой функции. И мы соглашаемся что такое надо исправлять, ведь если мы не дадим ему этой возможности, ему придется писать голый SQL, что сводит усилия ORM на нет.

                                                      Также code-first по своей сути исключает возможность cross database запросов, по крайней мере в мире .NET
                                                        +1
                                                        А что вам мешает проектировать нормально на моделях? Отношения есть, индексы есть, модели, которыми нужно управлять самим — есть.
                                                        0
                                                        code-first применим когда проект новый, и прежнюю базу можно выкинуть и создать новую по шаблону из кода.
                                                        Как только в базе появляются данные — база становится легаси. Наличие *любого* Undefined Behaviour на вашем пути миграции означает, что базу придётся мигрировать вручную, т.к. ORM с высокой вероятностью в чём-то напортачит, а закрытый (может быть) баг в его процедурах миграции — слабое для Вас утешение.

                                                        (цитирую почти один в один вот отсюда, и практически целиком согласен с автором: blog.jooq.org/2018/06/06/truth-first-or-why-you-should-mostly-implement-database-first-designs)
                                                          0
                                                          Хорошая статья, на Хабре есть перевод
                                                            +1
                                                            базу придётся мигрировать вручную, т.к. ORM с высокой вероятностью в чём-то напортачит

                                                            Вы же видите миграции ORM, как они могут напортачить?

                                                              0
                                                              Насколько я знаю, у подавляющего большинства инструментов минимальная поддержка миграции со сменой типов (обычно прямо сказано, что поддержки такой нет) — потому что такая смена типов есть один из самых типичных примеров UB в миграции с точки зрения ORM. В этом случае они, разумеется, не «портачат» — они просто отказываются работать, что правильно.
                                                                0
                                                                В этом случае они, разумеется, не «портачат» — они просто отказываются работать, что правильно.

                                                                Ну и вы скрипт миграции руками допишете. Что не так-то?

                                                              0
                                                              Что именно может напортачить ORM когда каждая миграция проверяется разработчиком?
                                                        0

                                                        В том то и дело, что нужен. Потому что каждый раз мапить вручную — это полный бред. Значит писать под каждый случай функцию, которая достанет данные и замапит. Какой практический смысл в этом?

                                                          +1
                                                          Для .NET такое уже сделали и я даже пользовался им на небольшом проекте. github.com/StackExchange/Dapper
                                                        0
                                                        А вы попробуйте написать запрос с 5ью джоинами и сложными условиями.

                                                        А давайте попробуем.


                                                        $query = User::find()->as('u')->with('articles');
                                                        if ($cond1) {
                                                          $query->joinWith('profile p');
                                                          $query->andWhere(['<', 'p.age', 18]);
                                                        }
                                                        
                                                        if ($cond2) {
                                                          $query->andWhere(['=', 'u.type_id', UserType::EXTERNAL]);
                                                        }
                                                        
                                                        $users = $query->all();
                                                        
                                                        // ------------------
                                                        // User.php
                                                        
                                                        class User
                                                        {
                                                          ...
                                                        
                                                          function getProfile()
                                                          {
                                                            return $this->hasOne('profile', 'user_id', 'id');
                                                          }
                                                        
                                                          function getArticles()
                                                          {
                                                            return $this->hasMany('articles', 'author_id', 'id');
                                                          }
                                                        }
                                                        

                                                        Как это будет с использованием SQL?


                                                        В результате должен быть список пользователей с заполненным свойством $user->articles, где находится список статей, написанных конкретным пользователем. Джойн естествено должен быть только если $cond1 == true, $cond1 и $cond2 зависят от параметров GET-запроса.

                                                          0
                                                          Это конечно псевдо-java-код но примерно так

                                                          StringBuilder sql = "Select articles from user "
                                                          if (cond1) {
                                                          join = ("join profile p on p.id = u.profile_id")
                                                          conditions.put("and p.age < :age")
                                                          }
                                                          if (cond2)
                                                          {
                                                          conditions.put("and u.type_id = :type")
                                                          }
                                                          sql = sql.append(join).append("WHERE 1=1 ")
                                                          condtions.foreach(sql::append)
                                                          SqlParameterSource namedParameters = new MapSqlParameterSource()
                                                          .addValue("age", 1)
                                                          .addValue("type": type);
                                                          return namedParameterJdbcTemplate.queryForObject(sql, namedParameters, User.class);

                                                          P.S. почему-то разметка поплыла не получается выровнять :-(
                                                            0

                                                            Ну во-первых, articles это отдельная таблица со своими полями. Во-вторых, вы как-то незаметно пропустили объявление 2 важных переменных, а это тоже дополнительный код, который надо писать, читать, и поддерживать. К тому же вам было лень писать SQL-операторы капсом, что тоже сказывается на читаемости. В-третьих, если я правильно понял, queryForObject возвращает один результат, а не список.


                                                            И даже если перевести ваш код в PHP, он все равно будет в 1.5 раза больше, чем код с ORM, и с увеличением количества WHERE и JOIN его будет больше. У меня 1 переменная для запроса, а у вас 4. И все их надо будет копипастить в другие места, где есть WHERE и JOIN. А если название колонки или таблицы в JOIN поменяется, то искать по всему коду и исправлять.

                                                              +3
                                                              ну я пропустил 2 переменные, а вы их просто захардкодили.
                                                              Говорить про читаемость вот этого вот странного порядка я даже говорить не буду
                                                              $query->andWhere(['<', 'p.age', 18]);

                                                              капс исправить можно, а вот порядок не очень.
                                                              представьте что вместо query for object аналогичный метод для списка. Это не принципиально.
                                                              А какая разница сколько переменных если они инкапсулированы внутри метода. Это же не глобальные переменные.
                                                                –3
                                                                Говорить про читаемость вот этого вот странного порядка я даже говорить не буду
                                                                $query->andWhere(['<', 'p.age', 18]);

                                                                Говорить на самом деле нечего — здесь все интуитивно понятно. Операция и два значения.
                                                                  0
                                                                  ну я пропустил 2 переменные, а вы их просто захардкодили

                                                                  Так в том и смысл, что вам надо их объявлять, и по-другому никак) И у меня в строке не join, а название связи, а аналога conditions вообще нет, захардкожены только сами условия, как и у вас.


                                                                  капс исправить можно, а вот порядок не очень

                                                                  Если вы напишете не капсом, то ошибки не будет, и так оно и останется, а если порядок другой поставите, то будет, и придется исправлять. Порядок нестандартный конечно, но он просто непривычный для вас. Аргументы могут быть довольно длинные, и так получается читабельнее, чем выискивать короткий оператор в середине строки. Но если хочется, порядок тоже можно поменять, переопределив класс запроса.


                                                                  если они инкапсулированы внутри метода

                                                                  Так речь о том, как поддерживать код метода. Естественно, если там никогда ничего не будет меняться, то неважно что там написано. Хотя написание тоже удобнее получается.

                                                                    0
                                                                    Так в том и смысл, что вам надо их объявлять, и по-другому никак)

                                                                    Можно точно так же захардкодить.
                                                                    Если вы напишете не капсом, то ошибки не будет, и так оно и останется, а если порядок другой поставите, то будет, и придется исправлять.

                                                                    Правильно настроенный check-style скажет все что думает о таком коде.
                                                                    Аргументы могут быть довольно длинные, и так получается читабельнее, чем выискивать короткий оператор в середине строки. Но если хочется, порядок тоже можно поменять, переопределив класс запроса.

                                                                    ну то есть это по сути класс-генератор sql запросов. Уверен если покопаться в java я таких же десяток найду только использующих стандартный синтаксис.
                                                                      0
                                                                      Можно точно так же захардкодить.

                                                                      Ну конкретно в этом случае можно заменить на конкатенацию, потому что в sql фактически только название таблицы, и ее можно считать началом джойнов. А если надо будет в SELECT поля по условию добавлять?


                                                                      Правильно настроенный check-style скажет все что думает о таком коде.

                                                                      Ну вот, не только дополнительный код писать, а еще и дополнительные инструменты настраивать. Зачем, в чем профит-то?


                                                                      ну то есть это по сути класс-генератор sql запросов

                                                                      Не только, потому что джойны заменяются на связи ( R ), описанные в классе, условие джойна генерируется по ним. Можно даже превратить в many-to-many без изменения вызывающего кода.
                                                                      И вы игнорируете что articles это таблица. ORM по связям определит ключи, сделает второй запрос с IN, и заполнит свойство articles у всех объектов в списке users. Для SQL будет джойн с дублированием строк таблицы users или еще одна портянка кода c ручным распределением.


                                                                      Уверен если покопаться в java я таких же десяток найду

                                                                      Ну так вы же предлагаете пользоваться SQL вместо них) Разговор не о том, что есть, а о том, чем пользоваться.

                                                              0
                                                              А все эти ваши joinWith и andWhere будут передаваться в виде динамических запросов движку бд, тем самым затрудняя оптимизацию?
                                                                0
                                                                Не знаю, почему вы так решили, из них потом генерируется обычная строка с SQL-кодом.
                                                                  0
                                                                  Обычная динамическая строка типа WHERE Age < 18 или обычная строка вида WHERE Age < @ARG01, @ARG01 = 18?
                                                                    0

                                                                    Если база поддерживает именованные параметры, то будет с параметрами.

                                                                0
                                                                А join на этот запрос вы сделать можете? А если там еще и группировка или урезанная по нескольким полям выборка?

                                                                Я веду к тому что в нормальных ORM используется не только фильтрация, а и в полный рост query decomposition. Склеиваете такие маленькие подзапросы, накладываея ограничения по доступу, и на выходе получаете взрослый оптимизированный запрос. Поверьте оптимизированный, намного лучше чем руками бы писал.

                                                                Сколько не смотрел на другие языки и их ORM, только .NET с его IQueryable позволяет такое делать типобезопасно и предсказуемо. Естественно зависит от linq провайдера. Мой выбор давно пал на linq2db
                                                                  0
                                                                  Там есть join и даже eager loading, select тоже можно указать если надо. Группировку мало смысла мапить на объект класса, обычно массив запрашивается.
                                                              +2
                                                              применяет ту же логическую ошибку, что и по всей статье — у вас нет единого SQL


                                                              Т.е. ребята из ISO и ANSI с 83-го года работают в пустую?
                                                                0

                                                                Классно, правда?)


                                                                Вот стандартизировали они json и толку?

                                                              0
                                                              Согласен с вами, но нужно смотреть глубже. Как в одной из лекций говорил uncle bob, может быть база данных вообще не нужна? И приводил пример того, как они строили свое приложение не пользуясь базой и добавили ее только тогда, когда один клиент специально на наличии базы настоял.

                                                          0

                                                          Не надо за ORM перепроверять. Если у вас запрос на 10 строк — пишите вручную, если хотите. А одну строку ORM сделает лучше и предсказуемее. Потому что защита от опечаток. Вы попробуйте просто.

                                                            +2
                                                            Защиту от опечаток дает IDE, так-то.
                                                            Я пробовал. У меня прямо сейчас открыт метод на 200 строчек который пишет сложный запрос на queryDSL
                                                              0
                                                              Защиту от опечаток дает IDE, так-то

                                                              Дает до поры до времени. И у всех иде разные.
                                                      0
                                                      Когда вас будет несколько — вы тоже не очень будете знать, какой же там запрос написал тот человек.
                                                      А как же code review?
                                                        0

                                                        Вы всей командой его проводите? У нас только один человек.

                                                          0
                                                          Да
                                                            +3
                                                            Вы классные, что я могу сказать :)
                                                      0

                                                      Сначала у вас функция, которая возвращает массив данных по клиенту. Потом вы захотите объект User. Потом, когда объектов много, вы захотите не делать под каждый объект функцию Something::getByID. Потому что зачем вам 50 одинаковых по сути функций?

                                                        0

                                                        Наверно, надо научиться пользоваться ORM?

                                                  0
                                                  Если вы пишете код не на хранимках, у вас в любом виде будет присутствовать свой слой маппинга и общения с базой, где с одной стороны будут объекты на вашем языке, а с другой стороны sql. И лучше если это будет гибернейт или майбатис, чем ваше самописное поделие или простыня resultSet.get*
                                                    0
                                                    Есть же копромисс. Например JDBC Template
                                                      0
                                                      Это не компромисс. Все равно вы будете вручную дергать employee.setId(rs.getInt(«ID»)) — и так все поля объекта. Чем это отличается от майбатиса лично мне не очевидно.

                                                        0
                                                        Не совсем понимаю о чем вы говорите. Я не понимаю как иначе можно собрать доменный объект из resultSeta. Только последовательно заполнить все поля.
                                                          +1
                                                          Я не понимаю как иначе можно собрать доменный объект из resultSeta. Только последовательно заполнить все поля.

                                                          Ну да. Что в этом хорошего? По сути орм избавляет вас от лишней работы.
                                                            0
                                                            JDBC Template точно так же избавляет вас от этой работы. Или я не понимаю о чем вы.
                                                  +2
                                                  А мне кажется в этом утверждении скрыт софизм! При наличии ORM, у меня в 6 местах будет один и тот же код по генерации этого «SQL» запроса. И поэтому я тоже эту простыню вынесу в отдельный метод. И, по итогу, при отсутствии ORM у меня в методе будет понятный SQL-запрос, а при использовании SQL — будет того же объёма код, генерящий этот запрос в терминах ORM, и как уже написали ниже, до результирующего SQL ещё поди доберись.

                                                  Вообще, как по мне, так с ORM ты по итогу приходишь к тому, что оборачиваешь их ещё одним слоем абстракции как раз из-за того, чтобы не дублировать код построения запросов. И в итоге понимаешь что на самом деле тебе хочется просто удобно (за минимум манипуляций) мапить результат выполнения запроса на сущность, сохранив возможность писать чистый SQL
                                                    0
                                                    Ну, метод для генерации пишется довольно просто в одну строчку, в отличии от работы с сырым sql, где вам еще надо как минимум создать коннект и выполнить запрос + скачать данные.
                                                      0
                                                      В одну строчку? Появились ORM которые читают мысли? Любой запрос сложнее «загрузи сущность по ID» — всегда несколько строк. И чем сложнее запрос, тем больше строк нужно написать для ORM, в сравнении с текстом SQL запроса.

                                                      С сырым SQL — создать коннект, выполнить запрос? Ровно так же, как и с ORM нужно получить сессию и отправить запрос на выполнение. Ровно тот же самый код
                                                  0
                                                  Кода вообще может и не быть — одни аннотации. И я даже не помню, когда я последний раз включал лог sql кода.

                                                  P.S. У дядьки явно бомбануло, ему бы подорожничек приложить.
                                                  +2
                                                  Что делать если ORM не поддерживает всех плюшек СУБД, потому что надо иметь один интерфейс для многих СУБД?
                                                    +2

                                                    Поменять ORM или отказаться от него. Серебряной пули не бывает, у любого решения есть как преимущества, так и недостатки. Но я ни за какие плюшки не перейду с хорошего ORM на чистый SQL.

                                                      0
                                                      хорошего ORM
                                                      Как понять хорошии или нет?
                                                        +1

                                                        По опыту использования скорее всего. Я вот пользуюсь одним ORM уже 10 лет, и если первые 3-4 года приходилось иногда писать чистый SQL, то в последнее время он развился до такого уровня, что я уже не могу вспомнить, когда мне в последний раз пришлось писать чистый SQL. При этом я постоянно просматриваю запросы, которые он генерирует, и меня в них все устраивает.


                                                        Так что на этот вопрос тоже однозначного ответа дать нельзя. Только читать документацию и пробовать использовать.

                                                          0
                                                          Можно узнать что за ORM?
                                                            +1
                                                              0
                                                              Django ORM уже научился в JOIN по двум условиям? или в JOIN не связанных через foreign key таблиц? или умеет генерировать SQL с WITH?
                                                              Django ORM хорош когда нужно сделать что-то простое, это и правда удобно. Когда же нужно сделать что то не стандартное то появляется ощущение что у тебя все колесо в палках.
                                                                0

                                                                И согласен, и нет.


                                                                Django is a quite opinionated framework. Со временем просто привыкаешь не писать поперек линованной бумаги, и количество палок резко снижается.


                                                                А вот с legacy database это полный ад, да.

                                                                  0
                                                                  «не писать поперек линованной бумаги» работает только когда в проекте только один Django пользуется базой и он же ее создает. В иных ситуациях код начинает состоять из кучи unmanage моделей и самописных SQL constraints. Кстати в текущую ветку Django вроде приняли патч добавляющий создание CHECK constraint из моделей.
                                                                    +1

                                                                    В качестве дисклаймера: я, на самом деле, django orm не люблю. Автокомплит в разных редакторах от плохого до омерзительного, паршивая расширяемость, куча магии плюс сильная заточка под OLTP, так что при малейших поползновениях в сторону аггрегации/аналитики удобней откатиться в сторону raw sql.


                                                                    Но вашей проблемы я не прочувствовал :)


                                                                    Если миграцией базы управляет django, то есть https://github.com/rapilabs/django-db-constraints, ну или на худой конец sql прямо в миграциях.
                                                                    Если база управляется извне, то в чем проблема c unmanaged моделями-то?
                                                                    Если же и так и так, то в проекте есть проблемы посерьезней, чем выбор орм =)

                                                                +1
                                                                Вот и нашелся человек который любит Django, а я уже начал жалеть питонистов. Я посмотрю как мы разрулим мою новую схему базы данных на нем, но что-то мне подсказывает это будет печально и превратится в склейку строк.
                                                                Перформанс из рук вон плох, и это даже не из-за Django, а из-за того что он мало чего позволяет из мира SQL.
                                                      +3
                                                      С ORM код становится проще и понятнее, и поддерживает автоматические плюшки типа миграций и рефакторинга.

                                                      Еще большинство ОРМ сами санитайзят параметры, т.е. бесплатная защита от инъекций.
                                                      Самому за этим везде следить — бОльшая вероятность допустить ошибку.
                                                        +1
                                                        0_о это привет родом из 90ых что ли? В любом нормально языке есть встроенный механизм защиты от SQL-injection. Для Java например это prepared statement. Говорить про sql-injection в 2018-ом просто неприлично.
                                                          +1
                                                          Ну про в любом нормальном языке — это вы загнули конечно, но в любой нормальной библиотеке — согласен.
                                                          Действительно проблема уже не очень актуальная, тем не менее до сих пор периодически натыкаюсь.
                                                            0
                                                            >Для Java например это prepared statement

                                                            И как сделать ps для SELECT когда количество входных параметров варируется? :)

                                                            Кстати, criteria API для РСУБД тоже монстр, в mongo API всё на порядок продуманнее. Ещё и транзакции прикрутили в Монго 4.

                                                            Итого сейчас муки выбора sql vs orm почти не возникают, т.к. почти всегда больше плюсов у mongo. Но ретрограды, конечно ещё не все умерли :)
                                                              0
                                                              В монге, кстати, тоже инъекции бывают, особенно при использовании языков с динамической типизацией (таких как javascript). Буквально недавно тут пост про них был…
                                                                +1
                                                                >В монге, кстати, тоже инъекции бывают, особенно при использовании языков с динамической типизацией

                                                                Уверен, что через java mongo API ничего такого в принципе не сделать. А проблемы вызывает обезьянний JS-код с использованием eval и прилепленными входными данными. Но это уже никак не проблема Монго.
                                                                  0
                                                                  Ну, я так понимаю, достаточно JSON.parse(), никакого eval не надо.

                                                                  const { name } = JSON.parse(query);
                                                                  userModel.findBy({ name: name });


                                                                  Вот в этом коде может быть инъекция
                                                                    –1
                                                                    Возможно неправильно понимаешь :) по крайней мере в статейках с высосанными из пальца примерами траблы вызывает именно JSON.parse() + eval.

                                                                    В твоем примере, допустим query пришло извне и никак не проверяется. В итоге, оно либо распарсится в объект, либо не распарсится. Где инъекция-то? :)
                                                                      0

                                                                      Вот тут: { name: name }. Автором кода предполагается, что name — строка, но реально тут может быть запрос любой сложности.


                                                                      Возможно, что утечки данных и правда не произойдет — но DoS через километровый запрос организовать можно и попробовать.

                                                                        +1
                                                                        В твоем примере, допустим query пришло извне и никак не проверяется. В итоге, оно либо распарсится в объект, либо не распарсится. Где инъекция-то? :)

                                                                        Ну ладно. Представьте такой код:
                                                                        const { name, token } = JSON.parse(query);
                                                                        userModel.findBy({ name: name, token: token });

                                                                        И вот пользователь вместо
                                                                        { name: 'Вася', token: '123e4567-e89b-12d3-a456-426655440000' }

                                                                        Передает такое:
                                                                        { name: 'root', token: { $ne: '1' } }

                                                                        Догадываетесь, какой будет результат?
                                                                          –2
                                                                          >Догадываетесь, какой будет результат?

                                                                          «прогера» будут больно пинать ногами на первом же ревью?

                                                                          Я даже у джунов никогда такой откровенно притянутой за уши ереси не встечал. Это не аналог SQL-инъекции, а из разряда взять и полностью выполнить SQL запрос пришедший с веба. Таким образом можно вообще любую СУБД положить, если делать максимально идиотские вещи.
                                                                            +3
                                                                            Ясно. Ну значит, инъекций нет. Монго — безопасная, а весь существующий софт — без уязвимостей, все джуны — проходят ревью, а синьёры — не допускают ошибок, а я — пошел кормить своего маленького единорожка.
                                                                              –1
                                                                              >Ну значит, инъекций нет

                                                                              Нет инъекций. Почитай для начала что это такое.
                                                                              Когда findBy(блабла) сделает insert(блабла) тогда и приходи.
                                                                                +1
                                                                                Синдром утенка от инъекций? Инъекция — это обязательно insert? Повышение привилегий или произвольное чтение — это тоже инъекция.
                                                                                  –1
                                                                                  В mongo java api нет вообще ничего из перечисленного, т.к. если в String засунуть { $ne: '1' } это просто не заработает.

                                                                                  Проблемы js-макак решайте без меня, если они есть. Все примеры выше выглядят очень сильно искуственными или вообще неработоспособными. Инъекция это или не инъекция мне тоже фиолетово.
                                                                                    +1
                                                                                    Цитирую:
                                                                                    В монге, кстати, тоже инъекции бывают, особенно при использовании языков с динамической типизацией (таких как javascript).

                                                                                    А ты сказал, что только если eval использовать. А я доказал, что это не так. Так зачем тут распинался, если тебя не волнует?

                                                                                    У тебя корона как у Джобса, а знаний и опыта как у краба. Подтянись немного перед тем, как в такие споры вступать и научись признавать свои ошибки.
                                                                                      –1
                                                                                      Какой настырный. ОСОБЕННО или ТОЛЬКО?
                                                                                      Если дыра у JS-макак, не надо со своей больной головы на Монго перекладывать.

                                                                                      Да у меня опыта в JS как у краба. И слава богу. И надеюсь не добавится.
                                                                                        0
                                                                                        Эта проблема возможна и на других языках если объектные модели используемые при десериализации JSON и при формировании запросов к монге случайно окажутся совместимыми между собой.

                                                                                        Пока что я о таких случаях не слышал, но это случайность. Разбирать JSON через DOM вместо десериализации индусы уже умеют, осталось дождаться когда JSON-десериализаторы научатся использовать BSON-объекты.
                                                                                          0
                                                                                          JS-макак

                                                                                          Ты — самовлюблённый сноб, ты знаешь об этом? Питон, кстати, имеет точно такую же уязвимость. И, главное, в Джава есть пакет com.mongodb.util.JSON, который точно так же позволяет произвольный JSON привести к Монге.

                                                                                          DBObject dbObject = (DBObject) JSON.parse(
                                                                                              "{ name: 'root', token: { $ne: '1' } }"
                                                                                          );

                                                                                          Скрытый текст
                                                                                          пс. Да, я знаю, что тут неправильные кавычки. Но мне влом для Джавы их выставлять
                                                                                            0
                                                                                            Мне это обсуждение напоминает так называемые вирусы под линукс. Читаешь новость, удивляешься, качаешь, компилишь, не компилится, патчишь, не работает — ах, чёрт, надо было ещё SELINUX выключить и из под рута запустить. И тогда дырявый линукс повержен.

                                                                                            Так и тут. В жабе есть куча сериализаторов получше. Но зачем прогонять через них непроверенное абы что и потом выполнять Монгой? Если считаешь, что это уязвимость в Монге, сделай себе инъекцию эвтаназии уже.
                                                                                              0
                                                                                              Ты глупый какой-то. Процитируй, где я говорил, что это уязвимость в Монге?

                                                                                              Это особенности использования. Если я буду ехать на спорткаре на полной скорости и специально въеду в дерево — это ведь не ошибка создателей спорткаров. Но я могу разбиться на спорткаре и это факт.

                                                                                              Так само и здесь. Монго — прекрасен, но любому, кто его использует важно понимать, что он не прикрыт со всех тылов, а он может наглупить и создать уязвимость в своем приложении
                                                                                                0
                                                                                                >кто его использует важно понимать, что он не прикрыт со всех тылов

                                                                                                ОК, открытие недели: если в Монго запустить некий код, этот код что-то сделает. Британские учёные отдыхают!
                                                                                                  +2
                                                                                                  Вашу дешевая демагогию применяйте на детсадовцев.

                                                                                                  Если в Монго передавать неотфильтрованный ввод пользователя, это может вылиться в уязвимость в вашем ПО. Это называется инъекция. Именно об этом мы и говорили. И именно о такой возможности вы еще пару дней назад не догадывались, а теперь стараетесь построить хорошую мину при плохой игре
                                                                                                    –1
                                                                                                    Единственное что я узнал из этой ветки — js-макаки совсем опухли и пихают напрямую dto в Монгу. При этом почему-то считают, что делаться будет не то, что в dto. Нормально чо…
                                                                                                      0
                                                                                                      > Единственное что я узнал из этой ветки — js-макаки совсем опухли и пихают напрямую dto в Монгу.

                                                                                                      Джава дебилы совсем охуели…
                                                                                                        +1
                                                                                                        Джава дебилы совсем охуели…

                                                                                                        Фу, как грубо. Джаву хороший язык и на нем пишут прекрасные программисты. Не стоит судить о всех по одному гнилому экземпляру

                                                                                                        0
                                                                                                        Единственное что я узнал из этой ветки

                                                                                                        То, что ты не способен к обучению и познанию — я уже понял. Но тут нечем гордиться

                                                                                                  0
                                                                                                  Если считаешь, что это уязвимость в Монге

                                                                                                  че за бред то? В каких вообще дб есть уязвимости к инъекциям? Ни в каких. Уязвимости в коде.
                                                                        0
                                                                        Я могу ошибаться, но Jdbc Template решают эту проблему с помощью именованных параметров.
                                                                        +1
                                                                        А вы знаете, что prepared statements локальны для каждого подключения к БД и что этих подключений может быть много и как только нужно создать ещё одно, все эти выражения «подготавливаются» и это может занимать ощутимое время?
                                                                          0
                                                                          А они не кэшируются?
                                                                            0
                                                                            Они вообще видимы только в пределах одного подключения к БД. В его пределах они кэшируются.
                                                                              0
                                                                              Так подключения тоже кэшируются(connection pool)
                                                                        0

                                                                        Во всех приличных СУБД защита от инъекций уже встроена. Используйте биндинги и враг не пройдёт.

                                                                      +4
                                                                      ORM дает общую обертку над кучей разных СУБД
                                                                      Как часто вы меняете СУБД?
                                                                        0
                                                                        Лично я — сталкивался с необходимостью поддержки разных БД пару раз и приходилось менять пару раз. И все разы доработки были минимальные, потому что работало всё из коробки.
                                                                          +1

                                                                          Меняем не часто а вот добавить новую — это вот бывает. У меня например через Eloquent безшовно связаны 2 таблицы одна из mysql а другая из postgres.


                                                                          Если бы писать запросы — тогда я бы путал сам язык запросов разных баз особенно если бы залез в этот код через пол года, а тут ORM сама генерит нужные запросы через лексер для нужной базы, и еще и хранит логическию звязь между таблицами.


                                                                          Напрмер вытянув первую сущьность я могу через нее вытянуть вторую и на лету обновить её, хотя вытянул из postgres а обновил в mysql и все это 3 строки кода.


                                                                          Запросами вышло бы на 20 без отлова ошибок.

                                                                            0
                                                                            А как вы проводите юнит тестирование запросов?
                                                                              +1

                                                                              Подымаем тестовые базы и на них гоняем тесты через phpunit.

                                                                            0

                                                                            У меня был случай, когда мы один набор сущностей писали в постгрес в нормализованном виде и параллельно в кликхаус для аналитики

                                                                          +11

                                                                          Вы же знаете, что на самом деле у каждой реляционной базы данных свой диалект SQL и этого вашего мифического "SQL", который единый стандарт не существует и каждую базу все равно надо изучать, так как какие-то фишки работают не так, а какие-то не работают?


                                                                          Следовательно пост не имеет никакого смысла.

                                                                            +7
                                                                            Следовательно пост не имеет никакого смысла.

                                                                            Странный вывод. Вспомнился текст из защиты Чуббаки
                                                                            Я вполне понимаю автора. Он хочет sql-подобный язык запросов. Он готов почитать специфику, но основная идея написания запроса должна быть похожая. И это есть в SQL, выборка пишется одинаково на любом диалекте, поддерживающем SQL92. Да, есть специфичные конструкции или функции, но они, как правило, расширяют стандарт. В случае с ORM, язык запросов часто настолько своеобразен, что без документации что-то написать сложно. Для примера, в мире Java есть Criteria API и JPQL. Последний сделали максимально похожим на sql, видимо была такая потребность. Наверное, дело вкуса, но читать даже небольшие запросы на Criteria API очень тяжело.
                                                                              +2

                                                                              Так уж повелось, что в мире Java все, что имеет официальную спецификацию JSR, неудобно и эстетически неприятно. Зато сторонние библиотеки типа QueryDSL исправляют ситуацию. В большом проекте подобные type-safe врапперы сильно спасают ситуацию, например, когда нужно найти все места, где используется какое-то поле или таблица.

                                                                                +1
                                                                                Мне кажется это очень похоже на SQL:
                                                                                List<Person> persons = queryFactory.selectFrom(person)
                                                                                  .where(
                                                                                    person.firstName.eq("John"),
                                                                                    person.lastName.eq("Doe"))
                                                                                  .fetch();
                                                                                

                                                                                Понятно, что синтаксис не один в один, но по логике формирования вполне. QueryDsl — это такой компромисс между типизацией из CriteriaApi и читабельностью SQL/JPQL.
                                                                                  +3
                                                                                  Угу только например тот же QueryDSL очень любит делать cross join по поводу и без. И без дебагера вы это не узнаете.
                                                                                    0
                                                                                    Дык не используйте его, пишите на нативном sql. Это можно сделать как в рамках queryDsl, так и вообще без ORM. Вы про другую проблему — проблему использования ORM в принципе. ORM не научилась угадывать мысли разработчика до конца и генерить идеальные запросы.
                                                                                      +3
                                                                                      Ну то есть инструмент для генерации запросов генерит плохие запросы. Зачем тогда нужен такой инструмент?
                                                                                        0

                                                                                        Потому что куча программистов напишет запрос еще хуже?)

                                                                                          –1
                                                                                          Спорное утверждение :-) SQL как-минимум удобнее писать и тестировать. IDE с удовольствием выполнит любой ваш SQL запрос, а вот если вы попробуете ей скормить какой-нибудь hql…
                                                                                            0

                                                                                            У девятой java вроде есть repl режим и можно интерактивно выполнять запросы и смотреть, что происходит.


                                                                                            У нас на python так сразу есть shell режим где можно оттестировать абсолютно все.

                                                                                              0
                                                                                              Это как минимум не так удобно. А в терминальном случае все-равно приходишь к тому, что надо смотреть сгенерированный SQL.
                                                                                          +1
                                                                                          Ну то есть инструмент для генерации запросов генерит плохие запросы

                                                                                          Не, не так. Вот так: инструмент для упрощения работы с БД, который позволяет не писать много SQL кода и в большинстве случаев делает это неплохо, иногда генерит неоптимальные запросы. Так вот для многих задач это не критично. А там, где критично, надо тюнить или использовать нативный запрос. Как-то так.
                                                                                            0
                                                                                            Проблема не в том, что он строит не оптимальные (не корректные) запросы. А в том, что ты не узнаешь, что он не корректный пока не отстрелишь себе колено по пояс.
                                                                                            Да, человек смертен, но это было бы ещё полбеды. Плохо то, что он иногда внезапно смертен, вот в чём фокус!
                                                                                              0
                                                                                              Есть такая фигня, тестирование называется…
                                                                                                +2
                                                                                                Есть такой параметр, называется сложность тестирование.
                                                                                                И если проверить sql запросто достаточно просто, то с запросо-генерацией все обычно чуть более запутанно. Да что там говорить, в гибернейте каждый релиз фиксят тонну багов. Я что-то не помню такого количества багов в SQL.
                                                                                                  –1
                                                                                                  И если проверить sql запросто достаточно просто, то с запросо-генерацией все обычно чуть более запутанно.

                                                                                                  В чем запутанность то? Включаем в опциях логирование запросов, получаем все sql запросы с параметрами. Дальше процедура ничем не отличается от sql запроса. В чем сложность-то?
                                                                                                  Полагаю просто, что в простоте тестирования sql есть лукавство. Его более-менее легко тестировать, когда ты сам его только что написал. А когда это другой человек и прошло пару месяцев с момента написания, тогда все будет обстоять ровно также как и с sql от ORM.
                                                                                                    +1
                                                                                                    И вот я делаю code-review и чтобы убедиться, что человек правильно написал ORM запрос мне нужно запустить среду со всеми флагами. Прямо в браузере из гита это сделаю, ага.
                                                                                                    Нормально написанный SQL нормально читается и через день и через месяц.
                                                                                                    Я же не говорю, что ORM плохо читается. Читается то он замечательно. Но не всегда делает то, что написано.
                                                                                                      0
                                                                                                      Читается то он замечательно

                                                                                                      Вот тут я бы поспорил, далеко не всегда.
                                                                                                      Но не всегда делает то, что написано.

                                                                                                      Делает то. Просто не всегда именно так, как вам хочется. Т.е. проверить запрос ORM именно на правильность несложно прямо в браузере, в code review (особенно какой-нить jpql).
                                                                                                      Но в целом, я понял вашу позицию, вам просто не нравится ORM или он не подходит для ваших сценариев использования. Тогда просто не стоит его использовать и мучатся.
                                                                                                        0
                                                                                                        убедиться, что человек правильно написал ORM запрос

                                                                                                        Можно человека попросить прислать вам что он нагенерит.
                                                                                                        Ну и в 99% случаев для более сложных запросов используют «голый» sql.
                                                                                                        И кроме того, вы достаточно уверены что во время review вы заметите где-то опечатку или то что все параметры правильно 'заэскейпены'?
                                                                                                          +2
                                                                                                          я где-то внизу уже писал про «эскейпинг». Если вы в 2к18-ом думаете об «эскейпинге» — в вашем проекте что-то не так.
                                                                                                            +1
                                                                                                            Возможно имелся в виду не совсем эскейпинг, а вставка параметров в запрос. По крайней мере это то, что не нравится мне в чистом sql. Вот пример с jdbcTemplate:
                                                                                                            String sql = "INSERT INTO CUSTOMER " +
                                                                                                            			"(CUST_ID, NAME, AGE) VALUES (:custId, :name, :age)";
                                                                                                            			
                                                                                                            		Map<String, Object> parameters = new HashMap<String, Object>();
                                                                                                            		parameters.put("custId", customer.getCustId());
                                                                                                            		parameters.put("name", customer.getName());
                                                                                                            		parameters.put("age", customer.getAge());
                                                                                                            			
                                                                                                            		getSimpleJdbcTemplate().update(sql, parameters);
                                                                                                            

                                                                                                            Тут все параметры типа Object. т.е. в age можно передать строку и это упадет только в runtime! И это еще запрос хорошо написан, с именованными параметрами, обычно для параметров просто используют вопросики и нужный порядок параметров. Только не надо говорить, что для этого есть код-ревью.
                                                                                                              0
                                                                                                              Возможно имелся в виду не совсем эскейпинг, а вставка параметров в запрос.

                                                                                                              Честно говоря я имел в виду именно эскейпинг, но валидация параметров — тоже неплохой пункт. Удобно когда поля уже заданы в модели и не надо об этом париться.
                                                                                                              0
                                                                                                              я где-то внизу уже писал про «эскейпинг». Если вы в 2к18-ом думаете об «эскейпинге» — в вашем проекте что-то не так.

                                                                                                              В нашем проекте совершенно точно «что-то не так», но не все проекты идеальные. Согласен что это не очень важная вещь, но лучше с ней чем без нее.
                                                                                                              0
                                                                                                              И кроме того, вы достаточно уверены что во время review вы заметите где-то опечатку или то что все параметры правильно 'заэскейпены'?
                                                                                                              Для этого есть тесты
                                                                                                                0
                                                                                                                Для этого есть тесты

                                                                                                                Вам везет )
                                                                                                    • UFO just landed and posted this here
                                                                                              +1

                                                                                              Я вот как раз сторонник вызова цепочки методов типа .select().where().where().fetch() вместо написания чистого SQL, особенно когда условия в where собираются динамично, т.е. может быть одно, а может и семнадцать, плюс пара джойнов, но красиво и понятно это выглядит только на простых запросах. Как только что-то чуть сложнее пары вложенных AND и OR с JOIN, так, как тут выше уже писали, без дебаггера и документации уже не разобраться, и быстрее выйдет написать SQL.

                                                                                                0
                                                                                                Вот поддержу! Построитель контролируемых запросов и маппер полей результата на объекты — действительно полезные инструменты.
                                                                                                Закулисная магия, порождающая медленных уродцев, богомерзкие актив рекорды и прочие протекающие абстракции годны лишь для прототипирования, да на личные поделки авторам ORM, на 100% понимающим как оно там внутри работает.
                                                                                                У остальных же кодеров, зачастую, отнимают больше времени, чем экономят.
                                                                                                  +3
                                                                                                  Смотря на каких проектах. Для highload-проектов возможно ORM — не лучшее решение. Но там и денормализацию приходится делать и много чего ещё.

                                                                                                  Для обычных CRUD-проектов же ORM очень сильно экономит время как на разработку, так и на поддержку. Просто за счёт отсутствия кучи бойлерплейта. Да, ORM может составить неоптимальный запрос, но это не всегда страшно. Даже если будет десяток лишних JOIN, то в базе с правильными индексами такой запрос всё равно будет обработан быстро. А потратив совсем чуток времени (даже не переписывая запрос на SQL, просто правильно настроив связи в ORM-запросе) всех этих лишних JOIN можно будет избежать.

                                                                                                  ORM — предсказуемая вещь по части получения результата. С этим проблем нет. Результат может быть получен не самым оптимальным образом, но это будет именно тот результат, который нужен. А оптимизация с точки зрения быстродействия/памяти далеко не всегда критична. Мне проще потратить лишнюю условную тысячу рублей на железо, чем тратить скажем 10 тыс. в месяц на дополнительную работу программиста на написание и поддержку чистых SQL-запросов.

                                                                                                  К тому же с ORM не такой уж и зоопарк. Для каждого языка программирования как правило не более 2-3 популярных решений, которыми все пользуются.
                                                                                                0

                                                                                                Да, в коде это выглядит на порядок понятнее, чем простыня из SQL. Кроме того, позволяет моментально отрефакторить или найти в проекте весь код, где есть обращения к конкретному полю. Поэтому я даже редко делаю кодогенерацию, а в замен использую aliases.


                                                                                                Есть еще офигенная библиотека JINQ, но она сейчас находится в standby. Хоть и рабочая, но с грядущими изменениями в JDK что-то боязно ее использовать в серьезном проекте.

                                                                                              –1

                                                                                              Ну вот автор пишет, что ему не понятен синтаксис mongo, хотя в основе там лежат абсолютно те же самые операции insert, select (называется find), update, delete.
                                                                                              Что ему не нравится? Синтаксис вызова этих операций?


                                                                                              И это есть в SQL, выборка пишется одинаково на любом диалекте, поддерживающем SQL92

                                                                                              Вы не правы. Например, прочитайте, например, вот это. Между тем же PostgreSQL и MySQL существует приличное количество различий, которые будут мешать. В этом и смысл моего комментария — стандарта SQL не существует и вам нужно каждый раз учить новый диалект SQL, когда вы работаете с другой базой данных. И разница с NoSQL базами данных лишь в том, что они честно сказали, что сделают свой язык запросов, потому что эмулировать sql и потом отходить от стандарта во всех местах для них не имеет никакого смысла.


                                                                                              Автор же, предполагая, что SQL в целом один раз можно выучить и готово совершает ошибку и вполне возможно знает SQL на том уровне, на котором любой язык запросов можно выучить за 1-2 день.

                                                                                                +3
                                                                                                Вы не правы. Например, прочитайте, например, вот это. Между тем же PostgreSQL и MySQL существует приличное количество различий, которые будут мешать.

                                                                                                Это просто еще один пример отступления от стандарта. То что реляционные базы это делают повод пожурить их, а не давать индульгенцию остальным.
                                                                                                  0

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


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


                                                                                                  Поэтому стандарт всегда будет нарушен, просто смиритесь с этим. Ну или штрафуйте, но конкретно в этом случае у вас не получится.

                                                                                                  +2
                                                                                                  По вашей ссылке ровно то, о чем я писал выше — отличие в деталях. Это проблема стандарта, который либо описал неудобное решение, которым никто не пользуется и делает свои, либо закрепляет что-то слишком поздно, когда пользователи уже привыкли к другому.
                                                                                                  По nosql на самом деле не все так очевидно. Не всегда можно/стоит натягивать SQL на то, что под него не задумывалось. И тут я не понимаю, почему автор критикует mongo. Но в случае некоторых ORM замечания вполне адекватны.
                                                                                                    0

                                                                                                    Ну так автор не пишет "ORM для реляционок, используйте реляционную терминологию", он пишет "требую натянуть SQL на все и заморозить разработку языков запросов", но как бы он даже на реляционки без различий не натягивается.

                                                                                                  –1
                                                                                                  Я вполне понимаю автора. Он хочет sql-подобный язык запросов

                                                                                                  Не-не-не. Посмотрите внимательнее на примеры, которые автор критикует. Минимум три из пяти — SQL-подобные языки и он их называет свалкой
                                                                                                  +2

                                                                                                  Вот да. Более-менее общепринятых стандартов SQL было несколько (89, 92, 99, 2003, 2008, википедия подсказывает, что есть еще 2011, и 2016). Причем, например, СУБД не может быть полностью быть SQL92-compliant и SQL99-compliant: стандарты противоречат в некоторых нюансах. Я из любопытства читал драфты этих стандартов — там изрядное количество какого-то лютого трэшака, который не реализует и не использует никто. Я не знаю, сколько надо выкурить самокруток из книг Дейта и Кодда и чем их надо забивать, чтобы придумать этот фарш. Ах, да, стандарт этот найти бесплатно не так-то и просто. Видимо из-за это оторванности от практики, закрытости и объёма этот стандарт никто не использует (в отличие от спек C++, C#, Java, ECMAScript и т.п.)
                                                                                                  Я вряд ли ошибусь, если скажу, что 99% "SQL-совместимых" СУБД это MySQL(+Maria), PostgreSQL, MS SQL Server, Oracle и SQLite. Да-да, я понимаю, что есть еще кучка древних и/или нишевых (IBM DB/2, Sybase/SAP ASE, Terradata, MS Jet, H2, Firebird и прочая экзотика, плюс стали появляться облачные движки), но основная часть всё-таки первая пятёрка. Так вот, даже в этой пятерке шаг в сторону от SELECT name FROM users WHERE age > 18сразу приводит к несовместимости. Именно поэтому поддержка нескольких СУБД не так-то и распространена, особенно без ORM. И, наверное, ни одна из них не реализует стандарт SQL.
                                                                                                  А как эти СУБД "реализуют стандарт SQL"? А по принципу шведского стола: СУБД выбирает чуть ли не до абзаца чему именно соответствовать и говорит "я поддерживаю SQL". На этом фоне MS C++ просто образец дисциплинированности реализации стандарта.
                                                                                                  И вишенкой на торте: у самих СУБД между версиями весьма большие различия.


                                                                                                  Так что, да, "стандартный SQL" это миф.

                                                                                                • UFO just landed and posted this here
                                                                                                  +3
                                                                                                  Мне кажется, автор оригинала троллит.

                                                                                                  ORM — это безусловно зло, но зло меньшее из возможных. Вопрос не в поддержке замены БД в любой момент, а в ортогональности системы типов любого языка и любой СУБД, не говоря уже о «стандартном» SQL, где она весьма маловменяемая. И в любом случае приходится делать трансляцию между этими несовместимыми системами типов каким-то способом.

                                                                                                  И если не нравится, что ORM слишком умничает/тупит, то для своего проекта можно же и собственную прослойку навалять, причём такую, чтобы и нативный SQL допускала. Мне вот однажды нужно было специализированную под bulk inserts, так я написал, использую иногда.
                                                                                                    +4

                                                                                                    Не факт. Я вот чем дольше программирую, тем меньше мне нравится концепция ORM… Она из серии "натянуть сову на глобус"… В реляционных БД нет никаких объектов и чтобы написать хороший запрос надо про объекты вообще забыть, а не пытаться как-то методы ORM в цепочку объединить. Да, само собой, в тривиальных случаях ORM работает хорошо, но если у вас что-то посложнее банального CRUD, то вам по-любому нужно знать SQL и проверять что там ORM сгенерил, а заставить ORM сгенерировать нужный запрос бывает тем ещё аттракционом.

                                                                                                      0
                                                                                                      В итоге — протекающая абстракция.
                                                                                                        +2
                                                                                                        надо про объекты вообще забыть, а не пытаться как-то методы ORM в цепочку объединить.

                                                                                                        C SQL вы будете не методы ORM в цепочку объединять, а условия для WHERE и таблички для JOIN-ов в массивах собирать. Во вложенных.

                                                                                                          +1
                                                                                                          в тривиальных случаях ORM работает хорошо, но если у вас что-то посложнее банального CRUD, то вам по-любому нужно знать SQL и проверять что там ORM сгенерил, а заставить ORM сгенерировать нужный запрос бывает тем ещё аттракционом.

                                                                                                          Так почему бы не использовать ОРМ для тривиальных случаев и рукописные запросы (которые практически во всех ОРМ поддерживаются) для нетривиальных? Учитывая что подавляющее большинство запросов — как раз тривиальные, то только профит.

                                                                                                            0
                                                                                                            Учитывая что подавляющее большинство запросов — как раз тривиальные, то только профит.
                                                                                                            Каждый тривиальный запрос со временем может превратится в не тривиальный, и что, переписывать каждый раз?
                                                                                                              +1
                                                                                                              Каждый тривиальный запрос со временем может превратится в не тривиальный, и что, переписывать каждый раз?

                                                                                                              Да, но к этому моменту у вас на каждый такой "переписанный" запрос появится сотня новых тривиальных, на которых вы сэкономите.

                                                                                                                +1
                                                                                                                Как будто вам не придется переписывать сам запрос когда он меняется с тривиального на нетривиальный :-)
                                                                                                          +2

                                                                                                          В целом я согласен с изложенным, хоть и на мой взгляд притянуто немало лишнего. ORM по мне вообще должен всё реализовывать через компилируемые функции, иначе, на мой взгляд, это будет вообще не ORM. Но вот хороших ORM и впрямь не хватает. Был вариант отображения хранимых процедур в EF через XML-описание, но потом от последнего варианта отказались, а в поддерживаемом теперь варианте в самом коде отображение хранимых процедур ушло на вечность в backlog. Про Hibernate не интересовался в последние годы, может хоть он лучше.


                                                                                                          Конечно, по мне неправильно притягивать сюда язык полнотекстовых запросов или запросов к разметке (XML, JSON). Не слышал, чтоб хоть что-то из этого входило в стандарт SQL, а запросы в XML и JSON нынче стандартизированы лучше, чем SQL. Вопрос, скорее, в избыточной на мой взгляд популярности JSON, т. е. в использовании его не только для тех целей, где он удобен, но и для тех, где он не очен удобен. Но это по мне совсем другой вопрос.


                                                                                                          Что за ORM подразумевался здесь, мне интересно, кстати. Может, тот самый Hibernate.

                                                                                                            0
                                                                                                            Речь про NHibernate, не знаю, есть ли у него большие различия с Hibernate =)
                                                                                                              0
                                                                                                              В удобстве использования на моей памяти всегда были, поэтому под .Net я предпочитаю EF. Но уж для Java он вряд ли может быть в чём-то хуже, чем NHibernate, разве что известное неудобство с value type в Java.
                                                                                                              +1
                                                                                                              Не слышал, чтоб хоть что-то из этого входило в стандарт SQL, а запросы в XML и JSON нынче стандартизированы лучше, чем SQL.

                                                                                                              C 2003 года XML точно входит: https://en.wikipedia.org/wiki/SQL/XML
                                                                                                              А вот SQL/JSON вроде только в 2016 году в стандарт добавили.

                                                                                                                0
                                                                                                                Пожалуй с точки зрения абстрактной архитектуры вы правы, но с точки зрения бытового применения — это будет тяжеловато тянуть, потому очень быстро начнут все городить костыли. Как собственно оно и случилось.
                                                                                                                +1
                                                                                                                Имхо тут дело даже не в тех, кто не знает и не хочет знать SQL, пытаясь что-то сделать через ОРМ, с такими и так все понятно. Имхо есть другая проблема — ряд людей, которые пытаются в реляционную базу пихать все подряд, старательно не замечая другие подходящие инструменты. Вот там да, без ОРМ все становится еще печальнее, однако ОРМ имхо в таком случае является костылем, прикрывающи основную проблему.
                                                                                                                  0
                                                                                                                  Хабы, куда приписан пост интересны: и «SQL», и «NoSQL». По тегам в дальнейшем будут искать — и находить этот пост, где про NoSQL (почти) ни слова, кроме как упоминание, что свалка данных без стандартного языка запросов — это зло. Странно, что в списке нет «системного администрирования» — как же, ведь БД крутятся на серверах, а ими занимаются системные администраторы! А заодно «сетевой безопасности», которую тоже можно притянуть за уши.

                                                                                                                  Давайте делать посты не поста ради, а так, чтобы позже их можно было найти и использовать по делу?
                                                                                                                    0
                                                                                                                    А в чем противоречие? NoSQL понятие широкое. Весь пост посвящен SQL'ю и всяким альтернативным «гибким» DSL (читай NoSQL).
                                                                                                                      0
                                                                                                                      Ну, посвящен он отсутствию SQL, а не NoSQL. А вот хаб на Хабре — понятие понятной «ширины», он для постов, где пишется на некоторую тему.

                                                                                                                      "У рыбы нет шерсти, но если бы была, то там жили бы блохи..."
                                                                                                                        0
                                                                                                                        Ну как бы DSL, особенно в виде ОРМ под которым SQL, это как бы нифига не NoSQL, на сколько мне кажется. Каким определением понятия NoSQL вы руководствуетесь?
                                                                                                                          –1
                                                                                                                          В NoSQL из SQL выкинули джоины, добавили поиск по блобам. Поскольку получившееся нечто формально SQLом назвать уже нельзя, а других приличных слов в голову не приходит, решили добавить «No» — так загадочнее.
                                                                                                                          Еще некоторые стесняются схемы «ключ-блоб» и с умным видом говорят: «а у нас тут вообще никакой схемы то и нет».
                                                                                                                            0
                                                                                                                            В RethinkDB, MongoDB вполне есть джойны…
                                                                                                                      +1
                                                                                                                      Не берусь рассуждать что там с ORM vs SQL, но разные *QL у «всех этих продуктах SaaS» существуют по той же причине, что и разные языки программирования: они предназначены для решения разных задач. Ну и кагбэ глупо требовать сделать «как в SQL-92» от NoSQL-СУБД с императивным языком.
                                                                                                                        0
                                                                                                                        Ага, причем большинство из примера — даже не реляционные базы. Но видать человеку не хватает в жизни JOIN'ов
                                                                                                                        0
                                                                                                                        я должен изучить 34 разных ORM
                                                                                                                        А еще все эти продукты SaaS

                                                                                                                        Что-то все в кучу. Каким боком Adwords это ORM?

                                                                                                                          +1
                                                                                                                          Как мне кажется тут речь идет о сильно раздутых api, в которых придуман чуть ли не свой специальный язык запросов, хотя под такой функционал вполне подошел бы обычный sql.
                                                                                                                          +1
                                                                                                                          Как насчёт ORM, нативной для языка, которая делает запросы типо-безопасными и защищает от тонн ошибок человеческого фактора в компайл-тайме (разумеется в этом случае ваш ЯП должен быть не из из разряда «garbage programming language», вроде javascript или php)?
                                                                                                                            0
                                                                                                                            Что это за ORM?
                                                                                                                              +1
                                                                                                                              Например «persistent»?
                                                                                                                                +2
                                                                                                                                Linq2Sql, Entity Framework, Linq2Db…

                                                                                                                                Нативная для языка часть называется LINQ (Language INtegrated Query)
                                                                                                                                0
                                                                                                                                Попробовали б вы так в мечети на HN…
                                                                                                                                +3
                                                                                                                                Автор не хочет учить все ORM. Я не хочу учить все подводные камни всех баз данных. Но ни ему, ни мне это и не нужно. Пара фреймворков и пара баз данных — вот реально необходимый в работе обычного специалиста объем знаний. А потом, всегда хочется абстрагироваться от реализации в пользу бизнес логики, сделать код более читаемым и удобным для написания. Я не хочу работать с конкатенацией строк каждый раз, когда составляю запрос. И я хочу автодополнение кода в IDE, когда пишу свои запросы. Я привык к прогрессу, и хочу пользоваться предлагаемыми им плюшками.
                                                                                                                                  +4
                                                                                                                                  Автор не хочет учить все ORM. Я не хочу учить все подводные камни всех баз данных.

                                                                                                                                  Проблема вот в чем. Автор не хочет учить ORM и может справиться без этого.
                                                                                                                                  Но вот лично вас подводные камни баз данных достанут в любом случае (на промежутке времени стремящемся к бесконечности).
                                                                                                                                  Потому что главное свойство абстракций — они протекают. И не сможет вас ORM от всего прикрыть, более того еще и своих проблем докинет для счастья.
                                                                                                                                  P.S. Idea замечательно умеет автодополнение для SQL.
                                                                                                                                    0
                                                                                                                                    Любой инструмент хорош применительно к чему-то. ORM мне хватит для решения большинства повседневных задач. Если появится задача, которая требует написания чистого SQL, я напишу этот запрос на чистом SQL. Потом оберну это в абстракцию на языке используемого мной фреймворка и задокументирую, почему пришлось так нестандартно поступить. Но, повторюсь, это — исключение.
                                                                                                                                      +1
                                                                                                                                      Если вы разрабатываете один — подход вполне себе жизнеспособный. Если вы в команде, то очень быстро приложение начинает жить своей жизнью. И вот уже кто-то разобрался в том, как воспользовавшись полудокументированым способом оптимизировать запросы для ORM (пример из реальной жизни с Hybernate) и начинает через это делать все. А кто-то другой поверх ORM нагородил Repository, а третий сверху построил MVC и еще один слой абстракции на JavaScript для клиентской стороны. И вот уже смена длины поля становится задачей на несколько месяцев.
                                                                                                                                      +1
                                                                                                                                      Вот кстати никогда не доводилось видеть продуктов где вопрос решался бы через структуру проекта. Я пробовал делать на своих pet-projects что-то вроде
                                                                                                                                      src
                                                                                                                                      +--sql
                                                                                                                                      +--packageXx


                                                                                                                                      и в sql складывать .sql файлики которые собирались как встраиваемые ресурсы. Таким образом их можно было отдельно тестировать и обеспечивалась связка с конкретной версией бинарника. А код работы с базой был в виде ВыполнитьЗапрос(ПолучениеЗаказовПоИд).

                                                                                                                                      Может быть кто-нибудь уже пробовал так же делать и может рассказать связанные с этим подходом грабли?
                                                                                                                                        0
                                                                                                                                        Я так не делал, но давно собираюсь
                                                                                                                                      +1
                                                                                                                                      мне кажется что абстрагироваться — это несбыточная мечта. Мы как-то мигрировали с одной субд на другую, и ORM нас не смог оградить от специфик субд.
                                                                                                                                      0
                                                                                                                                      мода, такая мода… не, ну соль конечно тоже есть, но повальное увлечение проходит… толстые клиенты -> тонкие клиенты -> толстые клиенты
                                                                                                                                        0
                                                                                                                                        Начнем с ORM. Их основная фича — это сокращение времени разработки

                                                                                                                                        Не просто разработки, а поддержки — тут кроется маленькая, но существенная разница.
                                                                                                                                          +2
                                                                                                                                          Сила SQL — в эффективности операций со множествами. Как только вы в имплементации того или иного бизнес-логического кейза утеряли возможность работы с данными, именно как с множеством (это не обязательно может быть уход в ORM и тред-итератор в процедурном ЯП — такое можно сделать и внутри самого SQL, соорудив курсор, скалярную функцию в условии поиска, или subquery в колонке-результате) — вы растеряли всю силу SQL.

                                                                                                                                            0
                                                                                                                                            Нормальные* ORM тоже позволяют работать с множествами…
                                                                                                                                            0

                                                                                                                                            ORM это в принципе зло. Как сказал кто-то, уж не помню кто, "если вы используете ORM, то вы массажист данных". Полного контроля ORM не дадут, поэтому если так хочется вместо языка SQL иметь запросы на языке вашего проекта, то есть query builder'ы, типа LessQL.

                                                                                                                                              +5

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


                                                                                                                                              Во-первых ORM в большинстве своем это таки DSL (domain specific language, где предметной областью является C(Q)RUD). То, что семантика распихана по нескольким файликам, часть из которых на привычном ОО-языке, не более чем попытка не слишком пугать программиста. Тот же Hibernate нормально преобразует все эти удобства в весьма формальную модель и генерит кучу байткода на лету, существенно не отличаясь от DSL компилятора.


                                                                                                                                              Во-вторых SQL как бы не работает с любой произвольной структурой данных. Как минимум требуется (даже логически) первая степень нормализации, чтобы можно было вообще произносить слово "таблица", а для слова "ключ", в его нормальном понимании, хорошо бы иметь как минимум вторую. Упомянутые вами Splunk и Lucene как раз специфические языки и придумывают от того, что "поток частично структурированных сообщений" и "некоторое количество коллекций гетерогенных слабо-структурированных документов" несколько не ложатся на любимые всеми таблички.


                                                                                                                                              В общем не надо бояться языков, тем более что большинство из DSL-ей простые как дрова. Если вы справились с SQL, маппингом в ОО, транзакциями через аспекты и реляционной алгеброй, все вариации на тему "100500 способов описать логический фильтр" для вас проблем не составят.

                                                                                                                                                +2

                                                                                                                                                Про ОРМ — настолько феерический бред, что не могу не отметиться.


                                                                                                                                                Все звучит красиво, пока твои потребности умещаются в select * from table. В реальности же… ну, давайте на примере DSL Django ORM (первое, что в голову пришло).


                                                                                                                                                queryset  = User.objects.all()
                                                                                                                                                if len(statuses) > 0:
                                                                                                                                                  queryset = queryset.filter(status__in=statuses)
                                                                                                                                                if last_comment:
                                                                                                                                                  queryset = queryset.filter(user__post__comment__сreated_at__gt=last_comment)
                                                                                                                                                if signed_in_from:
                                                                                                                                                  queryset = queryset.filter(signed_in__gte=signed_in_from)
                                                                                                                                                if signed_in_to:
                                                                                                                                                  queryset = queryset.filter(signed_in__lte=signed_in_to)
                                                                                                                                                
                                                                                                                                                cnt = queryset.count()
                                                                                                                                                admins = queryset.filter(is_admin=True)
                                                                                                                                                data = admins[:100]

                                                                                                                                                Знакомая ситуация? Думаю, да. Неужели кому-то по кайфу каждый такой запрос обписывать этим всем ворохом " AND ".join(chunks) и прочей бесполезной белибердой????

                                                                                                                                                  0
                                                                                                                                                  Я, как довольно активный пользователь ActiveRecord ORM (рельсы), могу сказать, что этого хватает на процентов, эдак, 95 всех задач. Он действительно хорош. Ещё процента 4 покрывает Arel — SQL AST, и, пожалуй, оставшийся 1 — это что-то совсем-совсем сложное, что нужно писать полностью руками.
                                                                                                                                                  Но это всё не отменяет того, что нужно хорошо понимать особенности работы БД, причём довольно глубоко