Розробка · 10 лютого 2014, 15:39 880

Igor Bilous, Java Developer

Java, де краще зберігати SQL запити?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Бачив два варіанта:
перший — зберігати в проперті файлах і конектити їх (як зазвичай) через спрінг
другий — зберігати в статичному класі

Який з них краще? Мені особисто більше імпонує перший варіант тому що,
— константа створюється тільки один раз, а не так як в першому варіанті коли треба створювати проперті і параметр в джаві
— в класі можна створювати внутрішні статичні класи і таким чином можна розмежовувати квері по завданнях\сервісах
— якщо клас не є біном то зяднувати проперті і клас потрібно через ResourceBundle або йому подібні а це лишній код + лишні стрінгові константи для шляху до проперті.

Я помиляюсь? А де ви зберігаєте ваші скл квері?

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Дмитрий Швейкус 11.02.2014 14:24

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

Відповісти

Підтримати

Juan Luis 10.02.2014 20:08

Вот тут можно почитать www.javapractices.com/...ction.do?Id=105 . По-моему, интересно.

Відповісти

Підтримати

Дмитрий Ковтун SDE II в Amazon 10.02.2014 16:53

Я дам такой ответ.
первый вариант это стрельба по воробьям из пушки. Почему?
properties в общем и в java в частности предназначены для хранения именовынных name-value пар для даных которые могут меняться от одного запуска программы к другому в зависимости от среды окружения. Поэтому в properties мы и храним в основном динамичное что то типа jdbc_pool_url или some_callback_url или rabbitmq_port и так далее. SQL в нашем случае это практически статические ресурсы (даже параметризированные). У вас не может же быть что сегодня sql1="select * from ...." а завтра этот же sql1="delete * from ...". Поэтому properties это не лучшее решение. Причем нужно учесть сколько дополнительного кода будет просто для размещение запросов в свойствах.

named query по моему мнению так же не очень хороший вариант так как он снижает readability. Я размещаю все query прямо непосредствено перед их вызовом ибо это наиболее наглядный способ ИМО.

Відповісти

Підтримати

Yuriy E 11.02.2014 16:16

Я размещаю все query прямо непосредствено перед их вызовом ибо это наиболее наглядный способ ИМО.

Офигеть, а потом приложуха просто валится. Лучше пусть хибернейт проверит.

Відповісти

Підтримати

Дмитрий Ковтун

Ivan Pomidorov 10.02.2014 15:57

Смотря какой у вашей команды тех. стек.

Если JPA/Hibernate, то можно использовать NamedQuery — хранить запросы в аннотациях.

Если JDBC/jdbc-template то можно хранить либо как static final константы прямо в классе либо как литерал прямо в вызове метода.

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

Еще отличный вариант — хранимые процедуры — их можно менять прямо на СУБД без остановки приложения.

Відповісти

Підтримати

Igor Bilous Java Developer 10.02.2014 16:01

речь идет имено о

JDBC/jdbc-template

Я просто сравнил сколько нужно всего чтобі сделать єто как проперти и подумал что намного легче это сделать через клас. Особено если на лету ничего менять не надо.
единственный минус это public ststic final в каждой строку

Відповісти

Підтримати

Ivan Pomidorov 10.02.2014 16:03

А какие запросы по размеру?

Відповісти

Підтримати

Igor Bilous Java Developer 10.02.2014 16:11

Всмысле ? длина строки? от пару сотен символов до 1000\1800

Відповісти

Підтримати

Ivan Pomidorov 10.02.2014 16:23

Тогда лучше все таки в пропертях. И инжектить через спринг по имени проперти в класс.

Відповісти

Підтримати

Igor Bilous Java Developer 10.02.2014 16:24

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

Відповісти

Підтримати

Ivan Pomidorov 10.02.2014 16:27

Потому что легче редактировать — можно многострочные запросы хранить. И не надо экранировать кавычки.

Відповісти

Підтримати

Igor Bilous Java Developer 10.02.2014 16:31

кавычек нету. Параметры передаю через NamedParameterJdbcTemplate.
редактирование — спорный вопрос. Запросы у меня все в одну линию. строки не переношу. так удобней когда запросов станет много. Когда нужно редактировать или запустить я запихиваю запрос в какой нибудь онлай форматер а потом после редактирования преобраховываю его в одну строку с помощью Блокнота++(ctrl + j). Звучит как то долго но на самом деле не так уж и долго.

Відповісти

Підтримати

Ivan Pomidorov 10.02.2014 16:46

Так в чем тогда вопрос? Кстати, советую подрубить SQL Developer чтобы гонять запросы и работать с базой.

Відповісти

Підтримати

Igor Bilous Java Developer 10.02.2014 16:49

вопрос простой: как лучше?). Мне было просто интересно чужое мнение.

SQL Developer

в интернете есть много по этому запросу. Какой девелопер вы имели ввиду?
ЗЫ: у меня(к сожалению) MS SQL

Відповісти

Підтримати

John Doe 10.02.2014 18:04

TOAD) — тут разночтений нет с таким названием)

Відповісти

Підтримати

John Doe 10.02.2014 18:02

Еще отличный вариант — хранимые процедуры — их можно менять прямо на СУБД без остановки приложения.

И куча других плюсов)

Відповісти

Підтримати

Igor Bilous Java Developer 10.02.2014 18:05

но если речь идет только о маленьких скл то смысл делать хранимые процедуры

Відповісти

Підтримати

John Doe 10.02.2014 18:12

С самого начала стоит все делать с прицелом на то, чтобы на уровне БД оказалось как можно больше. Это не значит что так обязательно должно быть, нет, очень многое проще делать и вне. Но зачастую многими простыми возможностями пренебрегают.

Відповісти

Підтримати

Ivan Pomidorov 10.02.2014 19:32

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

Відповісти

Підтримати

John Doe 10.02.2014 19:42

С чего вы решили что это сарказм?

Відповісти

Підтримати

Ivan Pomidorov 10.02.2014 20:13

Очень на это похоже.

Відповісти

Підтримати

John Doe 11.02.2014 17:52

Гм. Чем же?
Хранимки по дефолту очень кстати. Да и по поводу бизнес-логики можно обсуждать.

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись