|
|
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
У меня приложении появилось пару запросов для отчетов, которые не "ложатся" на criteria api, и на данный момент их вызов представляет из себя следующие: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Это я не в ручную форматировал, а скопировал из sql редактора с включенной в екслипсе функцией вставки многострочного текста . Мне не нравиться как это выглядит, читать все равно сложно, что толку от такого кода. Хочу вынести каждый запрос в отдельный sql файл и положить их в ресурсы, из которых он будет будет читаться в рантайм через getResourceAsStream. Как подобную задачу обычно решают? Или ни кто не париться и прямо так и оставляют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 12:12 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
MaxNevermindХочу вынести каждый запрос в отдельный sql файл и положить их в ресурсы, из которых он будет будет читаться в рантайм через getResourceAsStream. Как подобную задачу обычно решают? Или ни кто не париться и прямо так и оставляют. Это правильное решение. Другое правильное решение это унести запрос в SQL View, тогда он будет жить вместе с остальными скриптами миграции БД. Ведь если структура измениться, то и запрос надо менять. А при использовнии View, ошибка будет более явной в случае какой несовместимости изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 12:16 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
BlazkowiczMaxNevermindХочу вынести каждый запрос в отдельный sql файл и положить их в ресурсы, из которых он будет будет читаться в рантайм через getResourceAsStream. Как подобную задачу обычно решают? Или ни кто не париться и прямо так и оставляют. Это правильное решение. Другое правильное решение это унести запрос в SQL View, тогда он будет жить вместе с остальными скриптами миграции БД. Ведь если структура измениться, то и запрос надо менять. А при использовнии View, ошибка будет более явной в случае какой несовместимости изменений. Как вариант хранить внутри БД в виде stored procedure и дергать через callable statement. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 15:43 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
just_vladimirКак вариант хранить внутри БД в виде stored procedure и дергать через callable statement. Это лучше чем View? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 15:44 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
Blazkowiczjust_vladimirКак вариант хранить внутри БД в виде stored procedure и дергать через callable statement. Это лучше чем View? имхо, меньше лишних приседаний при необходимости передачи параметров, при сохранении тех же плюсов (контроль соответствия запроса текущим структурам данных). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 16:07 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
just_vladimir, это всё равно, что говорить: "функция лучше процедуры". Параметры либо нужны, либо нет. Отсюда однозначный вывод для хранимки или вьюшки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 16:18 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
Petro123, ок, тогда вопрос - в чем плюсы view по сравнению с функцией/процедурой без параметров? Я за единообразие - везде процедуры, чем зоопарк, здесь нужны параметры будет процедура, а здесь не нужны, по этому будет view. Как по мне, дак view нужны для других задач... я бы сказал, что это своего рода инструмент повторного использования кода, возможно некоторой инкапсуляции структуры БД, но не для этой задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 16:40 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
just_vladimirок, тогда вопрос - в чем плюсы view по сравнению с функцией/процедурой без параметров? В oracle плюс в том, что, когда накладывается условие поверх вью/процедуры, оптимизатор лучше работает с вью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 16:50 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
just_vladimir, отличий оооочень много. Например, Код: java 1. вложенные подзапросы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 16:52 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
Alexey Tomin, да, это логично, но в этом случае просто проще затащить этот параметр внутрь процедуры. Petro123, не понимаю о чем Вы, я разве говорил о том, что это одно и тоже? Либо я туплю, либо Вы немного на своей волне :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 17:03 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
Кстати, раз уж в начальном посте промелькнуло criteria api, то можно сделать вывод, что речь про JPA, либо hibernate. И там и там есть механизм для хранения запросов - Named Query. Можно загонять в аннотации, можно - в ресурсы (xml) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 17:13 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
just_vladimir, а мне второй ответ топика больше понравился)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 17:20 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
ivanraКстати, раз уж в начальном посте промелькнуло criteria api, то можно сделать вывод, что речь про JPA, либо hibernate. И там и там есть механизм для хранения запросов - Named Query. Угу. Аннотация на несколько десятков строк смотрится особо изящно. ivanraМожно загонять в аннотации, можно - в ресурсы (xml) И польза от хранения в XML какая? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 17:24 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
BlazkowiczИ польза от хранения в XML какая? Это то, о чем вопрос в первом сообщении. Можно, конечно, в произвольном ресурсе хранить, но раз уж речь про JPA/Hibernate, то зачем себя мучить запросами, возращающими массивы Object, если можно сразу получить осмысленные объекты. Аннотации тут действительно никакой красоты не дают, но могут пригодиться при отладке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 17:55 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
just_vladimirAlexey Tomin, да, это логично, но в этом случае просто проще затащить этот параметр внутрь процедуры. Petro123, не понимаю о чем Вы, я разве говорил о том, что это одно и тоже? Либо я туплю, либо Вы немного на своей волне :) Петро о том же. А втащить внутрь процедуры всё, что только можно использовать- это нереально- будет 20 параметров и всё одно захочется 21й. Для тех случаев, когда можно сделать view - надо делать view, это путь гораздо лучше и с точки зрения работы сервера, и с точки зрения администратора. Да и вообще- view - это почти таблица. Плюс править проще- поправил view и тебе и чтение, и запись, и вставка- всё готово. Если надо извратиться- "instead of" триггера. А функции- всё же вещь в себе. Плюс из багов оракла, которые меня били по башке, едва ли не все были связаны с pipeline function (т.е. процедуры). Каких только чудес не встречал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 09:05 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
в спринге где-то был класс-обертка для sql запросов, позволяющий задавать текст запроса в спринговой xml-конфигурации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 09:17 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
just_vladimirPetro123, ок, тогда вопрос - в чем плюсы view по сравнению с функцией/процедурой без параметров? Я за единообразие - везде процедуры, чем зоопарк, здесь нужны параметры будет процедура, а здесь не нужны, по этому будет view. Как по мне, дак view нужны для других задач... я бы сказал, что это своего рода инструмент повторного использования кода, возможно некоторой инкапсуляции структуры БД, но не для этой задачи.Однообразие ради однообразия никому не нужно. view - наиболее подходящее здесь решение: 1) С ними легче работать, так как не нужно изучать процедурную составляющую, которая сильно меняется от базе к базе. 2) С ними легче интегрировать такие вещи, как JPA/Hibernate/MyBatis 3) Они дают переиспользование кода, в отличие от процедур 4) Они эффективнее процедур, так как не требуют дополнительных шагов. Процедуры нужны совершенно для другого - для обработки данных, которая выходит за рамки возможностей SQL. В это случае можно либо вытащить данные в Java, и обработать их там, либо же обработать их на стороне СУБД, вернув только результат. Очевидно, что в очень многих сценариях второй вариант эффективнее. В таких случаях процедуры и используют. В случае автора правильным решением будет записать этот запрос _ПРЯМО_В_КОДЕ_, вынеся его в static final String константу - это абсолютно нормальная практика, и эффективнее этого ничего не придумать. Для уменьшения количества текста можно прибегнуть ко вьюшке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 11:12 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
Alexey TominПлюс из багов оракла, которые меня били по башке, едва ли не все были связаны с pipeline function оооо да! ))) +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 11:28 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
scfв спринге где-то был класс-обертка для sql запросов, позволяющий задавать текст запроса в спринговой xml-конфигурации. проще через CDATA ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 13:57 |
|
||
|
Как вы обычно храните raw sql запросы?
|
|||
|---|---|---|---|
|
#18+
pitongscfв спринге где-то был класс-обертка для sql запросов, позволяющий задавать текст запроса в спринговой xml-конфигурации. проще через CDATA Одно другому разве мешает? Хранить SQL в XML без CDATA это автоматически обречь себя на будущий геморой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 14:08 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38824462&tid=2126139]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
158ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 200ms |
| total: | 444ms |

| 0 / 0 |
