|
|
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
Как написать на Hibernate так, чтобы производительность была нормальной в случае множественного update(delete). К примеру, такая простая ситуация - есть таблица СОТРУДНИК и таблица ДЕПАРТАМЕНТ, и сотрудник принадлежит департаменту. Нужно увелечить зп всем сотрдникам из департамента. На SQL это будет просто update emp set salary = 1.1*salary whew dep_id = @dep_id, а на Hibernate как быстрее? Можно вытянуть коллекцию всех сотрудников из департамента, пробежаться по ним, проставить им зп и сохранить -но так это же медленно будет! СкажитЕ, как с этим поступать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 12:47 |
|
||
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
Используйте запросы. Вытаскивать объекты никакого смысла нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 13:03 |
|
||
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
М.ГоловановИспользуйте запросы. Вытаскивать объекты никакого смысла нет. Т.е. вы хотите сказать, что эту часть бизнес-логики следовало бы написать на SQLl, используя JDBC? Но в этом случае ещё ладно, а вообще, тогда таких узких мест может оказатья немало, а мешать SQL и Hibernate - плохо, смешение двух разных идеологий. Или я ошибаюсь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 13:08 |
|
||
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
jdo123 М.ГоловановИспользуйте запросы. Вытаскивать объекты никакого смысла нет. Т.е. вы хотите сказать, что эту часть бизнес-логики следовало бы написать на SQLl, используя JDBC? Но в этом случае ещё ладно, а вообще, тогда таких узких мест может оказатья немало, а мешать SQL и Hibernate - плохо, смешение двух разных идеологий. Или я ошибаюсь? В Apache OJB был объект Query, через который гонялись запросы, не относящиеся к объектно-реляционному маппингу (типа умножить все значения поля на 1.5). Есть подозрение, что в Hibernate тоже есть что-то подобное. Таким образом, ты используешь средства самого Hibernate для решения задачи. Фетчить строки в объекты действительно нет никакого смысла - они же вам не нужны на данном этапе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 13:26 |
|
||
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 14:06 |
|
||
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
jdo123Т.е. вы хотите сказать, что эту часть бизнес-логики следовало бы написать на SQLl, используя JDBC? Но в этом случае ещё ладно, а вообще, тогда таких узких мест может оказатья немало, а мешать SQL и Hibernate - плохо, смешение двух разных идеологий. Или я ошибаюсь? А без этого все равно никуда не деться в реальной задаче. Единственный вариант сохранить единую идеологию - делать ВСЕ на SQL. Потому что возможности ЛЮБОГО ORM очень ограничены. В задачах, предусматривающих анализ данных, массовые изменения, ORM неэффективен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 14:42 |
|
||
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
Ну а возвожности SQL вообще безграничны То что положено юпитеру не положено SQL задача какая-то подозрительная ... с чегой-то всем сразу подняли зарплату, и это необходимо писнуть ??? на самаом деле всё было так сотрудники ассоциируются с опрделёнными объектами - разрядами инкапсулирую- щими логику начислений. и ваши массовые update это просто однократные изменения ставок в этих разрядов ORM это гибкое счястье - вас же не заставляют работать c OOCУБД - захотели пишем SQL, предварительно инкапсулировав его, чтоб в случае чего переделать не затрагивая остальное о как, а ещё эффективнее массовые update делались на аппаратных накопителях без всяко ОСи ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 16:31 |
|
||
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
jdo123 М.ГоловановИспользуйте запросы. Вытаскивать объекты никакого смысла нет. Т.е. вы хотите сказать, что эту часть бизнес-логики следовало бы написать на SQLl, используя JDBC? Я хочу сказать - Hibernate запросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2006, 17:23 |
|
||
|
Производительность Hibernate в случае множественного update(delete)
|
|||
|---|---|---|---|
|
#18+
jdo123 М.ГоловановИспользуйте запросы. Вытаскивать объекты никакого смысла нет. Т.е. вы хотите сказать, что эту часть бизнес-логики следовало бы написать на SQLl, используя JDBC? Но в этом случае ещё ладно, а вообще, тогда таких узких мест может оказатья немало, а мешать SQL и Hibernate - плохо, смешение двух разных идеологий. Или я ошибаюсь?Ты ошибаешься. Читай POJOs in Action, здесь на форуме давали ссылку. Там на каждой странице написано, что делать через Hibernate то, что делается наиболее эффективно SQL, признак тупости разработчика. Идеология Hibernate в том, чтобы при разработке ООПрограмм снять с разработчика рутину работы с базой данных через SQL, но при массовых updateах ничего лучше SQL еще не придумано и Hibernate для этого не предназначался. В крайнем случае в книге советую iBATIS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2006, 20:48 |
|
||
|
|

start [/forum/topic.php?fid=59&fpage=752&tid=2150281]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 203ms |
| total: | 347ms |

| 0 / 0 |
