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

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

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

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

Я дам такой ответ.
первый вариант это стрельба по воробьям из пушки. Почему?
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 прямо непосредствено перед их вызовом ибо это наиболее наглядный способ ИМО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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