Добрый день,


В сиквеле у меня есть такой тип:



Я вызываю хранимую процедуру таким образом:


Это если в Management Studio.

Как тоже самое сделать из Java/Hibernate?

Спасибо.

Андрей Панфилов,

А через Hibernate это возможно? У нас девелоперы его везде используют.

Андрей Панфилов,

Я не программер, а ДБА. Мне девелоперы говорят, что не могут в хранимку передать список значений, ибо они используют Hibernate. Я не понимаю, либо они лукавят и просто не хотят работать с хранимками, либо это tool (hibernate) просто не заточен на SQL Server и лучше работает с Ораклом.

Озверин,

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

Petro123Roust_m,
У них ни одной хранимки или есть все таки?

Есть, но только те, которые получают небольшое количество параметров, а не таблицы или списки.

В общем идея у них такая: минимизировать использование хранимок, за исключением случаев когда их автоматически построенные запросы полностью убивают performance базы.

Petro123,

Оно может и красиво технически, но эти все девелоперские штучки: наследование, полиморфизм и прочие полностью убивают базу.

Андрей ПанфиловRoust_mЯ не программер, а ДБА. Мне девелоперы говорят, что не могут в хранимку передать список значений, ибо они используют Hibernate.Индюки небось? Давайте поясню для "ДБА": hibernate - это ОРМ, он всего лишь реализует некую "концепцию" доступа к БД, т.е.:
- позволяет декларативно описать в java-коде таблицы БД и связи между ними
- поддерживает условно "правильный" жизненный цикл жава-объектов, связанных с таблицами БД (поддержка транзакций, правильный порядок CRUD операций, и т.п.)

на этом все, т.е. хранимые процедуры - это вообще не про ОРМ, это в чистом виде императивщина и является расширением БД над реляционной моделью, поэтому ожидать, что ОРМ умеет хранимые процедуры, скажем, несколько наивно, да, там есть какая-то базовая поддержка, но в данном случае у вас используются расширения вендора в виде user defined types. Меж тем нет ничего зазорного в том, чтобы просто взять и там где нужно использовать "альтернативную концепцию доступа к БД" - никто от этого не умрет, нужно только позаботиться о том, чтобы с транзакциями было все правильно.

Вот я и не понимаю, они говорят, что это работает в jdbc, но не в Hibernate. Почему нельзя использовать jdbc в этом конкретном случае? Просто из-за того, что это не феншуйно? Или серьезная причина есть?

Petro123Roust_mPetro123,

Оно может и красиво технически, но эти все девелоперские штучки: наследование, полиморфизм и прочие полностью убивают базу.я фигею.
- наследования там нет
- ОРМ только для CRUD а не отчетов.
Докажите что убивает базу.

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

ОзверинRoust_m, а они как-то без jdbc работают с базой из хибера?

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

Petro123Roust_mПочему нельзя использовать jdbcархитектор в штате есть? Есть, но это не я к сожалению. Поэтом решений на чем разрабатывать под сиквел принимать не могу. Странно немного сиквел, джава и хибер. Было бы логичнее Дот Нет. Но увы... Возможно так исторически сложилось.

Petro123Roust_m,
Мне жаль. Другого способа взять коллекцию из базы нет.
Или ты против АппСервера?

Почему нет? Вызов jdbc. Вот только не феншуйно это...

maytonДавайте поможем DBA написать передачу списка параметров в хранимку через JDBC и это будет уже рабочее предложение с которым можно выйти как с альтернативой.

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

Petro123mayton,
Есть архитектор в штате, но дба погнал волну на него и на прогеров.

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

Petro123Roust_m,
А ты против хибера даже для маленьких таблиц?

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

Petro123Roust_m,
Ты ДБА?
Займись своей работой - делай тестовую площадку, генерируй базу и делай нагрузочный тест по ТЗ.

Я занимаюсь своей работой, мне поставили задачу переделать модель базы и перейти на хранимки. Потом последовали вводные: вызов хранимок это много кода, модель дожна быть заточена под хибер, а хибер требует особые фичи в модели базы, которые не позволяет делать некоторые вещи с базой, например партицирование. В итоге приходим туда откуда ушли: с хибером база еле дышит, ожидаем в 10 раз больше пользователей и больше функционала.

Petro123Roust_mхибером база еле дышит,цифры давай

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

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

Petro123Roust_mТут никто этого не отрицает, ни архитектор, ни программеры.а тут на форуме полно проектов с хибером. Что не так?

Roust_mПросто я всегда пытаюсь проблему решить, не убивая при этом отношения с коллективом.ты понимаешь, что БЛ в хранимках или АппСервере это Конфликт в коллективе?

Я этих проектов не видел, поэтому комментировать не могу.
Любые проблемы и разногласия можно решить без конфликтов. Главное не переходить на личности и помнить, что это просто работа.