JOOQ против SQL запросов - PullRequest
       6

JOOQ против SQL запросов

3 голосов
/ 28 февраля 2020

Я сейчас на jooq-запросах ... Я чувствую, что SQL запросы выглядят более читабельными и понятными, и поэтому нам нужно использовать JOOQ вместо собственных SQL запросов.

Может кто-то объяснит мало причина использования того же самого?

Спасибо.

1 Ответ

8 голосов
/ 28 февраля 2020

Вот предложения наивысшего значения, которые вы никогда не получите с нативным (на основе строки) SQL:

  • Dynami c SQL - это то, чем является jOOQ действительно очень хорошо. Вы можете составлять самые сложные запросы динамически на основе пользовательского ввода, конфигурации и т. Д. c. и все же будьте уверены, что запрос будет выполняться правильно.
  • Часто недооцениваемый эффект динамичности c SQL заключается в том, что вы сможете думать о SQL как о алгебре, потому что вместо писать трудный для составления собственного синтаксиса SQL (со всеми ключевыми словами и странными правилами скобок и т. д. c.), вы можете думать с точки зрения деревьев выражений, потому что вы эффективно строите дерево выражений для своих запросов. Это не только позволит вам реализовать более сложные функции, такие как SQL преобразование для мультитенантности или защита на уровне строк , но каждый день такие вещи, как преобразуют набор значения в SQL операции набора
  • Независимость от поставщика. Как только вам нужно поддерживать более одного SQL диалекта, написание SQL вручную практически невозможно из-за множества тонких различий в диалектах. Документация jOOQ иллюстрирует это, например, с помощью пункта LIMIT . Если у вас возникла проблема, вы должны использовать либо JPA (язык запросов с очень ограниченным доступом: JPQL), либо jOOQ (практически нет ограничений в отношении использования SQL).
  • Безопасность типов. Теперь вы получите безопасность типов при написании представлений и хранимых процедур, но очень часто вы хотите запускать ad-ho c запросы из Java, и нет никакой гарантии относительно имен таблиц, имен столбцов, столбцов типы данных или правильность синтаксиса, когда вы делаете SQL в виде строки, например, используя JDB C или JdbcTemplate, et c. Кстати, jOOQ рекомендует вам использовать столько представлений и хранимых процедур, сколько вы хотите. Они идеально вписываются в парадигму jOOQ.
  • Генерация кода . Что приводит к большей безопасности типов. Ваша схема базы данных становится частью вашего клиентского кода. Ваш клиентский код больше не компилируется, если ваши запросы неверны. Представьте, что кто-то переименовывает столбец и забывает реорганизовать 20 запросов, которые его используют. Среды IDE обеспечивают лишь некоторую степень безопасности при написании запроса в первый раз, они не помогают вам при рефакторинге схемы. С jOOQ ваша сборка не удалась, и вы можете решить проблему задолго до того, как вы go запустили в производство.
  • Документация. Сгенерированный код также действует как документация для вашей схемы. Комментарии к вашим таблицам, столбцы превращаются в Javado c, который вы можете анализировать на своем клиентском языке, без необходимости искать их на сервере.
  • Привязки типов данных очень просто с jOOQ. Представьте себе использование библиотеки из 100 хранимых процедур . Мало того, что вы сможете безопасно получать доступ к ним типа (посредством генерации кода), как если бы они были настоящим Java кодом, но вам не нужно беспокоиться об утомительной и бесполезной активности привязки каждого параметра in и out к тип и значение.

Существует множество более сложных функций, основанных на вышеприведенном, таких как:

И, если вы время от времени думаете, что что-то гораздо проще сделать с простым родным SQL, тогда просто:

Отказ от ответственности: Поскольку я работаю на продавца, я явно предвзят.

...