CknownИндексы вообще-то RDBMS строит или ты о чем?Да, и использовать их на СП нет никакой возможности. В том вся и проблема.
CknownА bookmark lookup это что? Ниасилил.Это такой специальный clustered index seek в MSSQL.
CknownЭто в .NET сделали контроль границ массивов и типов как в Java, слизали короче. Или ты не в курсе? А что еще ты не знал?Да мне всё равно кто там у кого лизал. Просто хотел узнать, есть или нет. Сказали что есть - хорошо.
CknownАлё, баян про "тормоза" управляемых сред уже обошел весь интернет 2 раза, ссылку уже давалиДелаем пузырьковую сортировку на C++ и java, и сравниваем. .Net отстаёт где-то в 1.5 раза. Думаю, что java будет примерно также. Поэтому делать циклы для обработки больших объёмов данных в managed среде крайне неэффективно. Managed придумано не для этого.
Вот , я как-то интересовался этим вопросом. 12 секунд на C++, 19 секунд на C# с проверкой границ. Без проверки работает примерно как С++. Совсем немного отстаёт.
fyndaНо я-то, мля, тебе не серверный код давал! Неужели совсем ничего не шевельнулось, чтобы подумать, что это неспроста? Ведь предупредил же - не пиши первую бредятину, которая придет в голову, так нет, нате вам:А нахрен "это" делать на клиенте, если все данные на сервере?
fyndaметод doSomeEntityModifications может кроме тупого и банального Update одной таблицы сделать с объектом entity еще туеву хучу всего - поменять данные в связанных с ним сущностях, добавить/удалить элементы в содержащиеся в нем коллекции, показать юзеру форму, где тот введет новые данные, получить их автоматически с сервера в Нью-Йорке (или еще где-то по выбору пользователя), считать со спецсекретной железки ежеминутные показания датчика радиоактивности за прошлые сутки и так далее, и так далее... Суть в том, что он может делать с объектом все, что угодно, и все эти изменения попадут на сервер в результате одного единственного вызова session.save(). Мало того - если завтра поменяется структура этого объекта, алгоритм его модификации, источники данных, его маппинг на базу данных, поменяется сама база данных и сервер, на которой она крутится - даже тогда с достаточно высокой вероятностью в код изменений вносить вообще не придется. Потому что он заточен не под тупую модификацию табличек и не под то, как что-то сделать, а под то, что именно надо сделать. И это правильноЕсли там много операций, по изменению Entity, то мутим хранимую процедуру, как предложил grexhide. Тогда кроме тупого и банального Update одной таблицы можно сделать с объектом entity еще туеву хучу всего - поменять данные в связанных с ним сущностях и т. д. Суть в том, что хранимая процедура может делать с данными на сервере все что угодно. Дальше продолжать?
fyndaМало того - если завтра поменяется структура этого объекта, алгоритм его модификации, источники данных, его маппинг на базу данных, поменяется сама база данных и сервер, на которой она крутится - даже тогда с достаточно высокой вероятностью в код изменений вносить вообще не придется. Потому что он заточен не под тупую модификацию табличек и не под то, как что-то сделать, а под то, что именно надо сделать. И это правильно.
Аминь...
ЗЫ: Сами себе проблемы создаёте, потом героически их решаете. Молодцы, так держать...
Cknown Алексей К fyndaРазумеется, восьмиэтажный запрос с помощью
hibernate соорудить будет сложненько, но обычные банальности вроде
select count(*) from where a=b делаются вполне. А для редких извращений
всегда есть возможность заюзать Native SQL.Дык вот в том-то и проблема, у нас бизнес логика без восьмиэтажных запросов не обходится. А, ну знамо, что-то с логикой. martinfowler.com в руки. Даже название библии подскажу: Приемы проектирования архитектуры промышленных приложений. Domain Driven Design придумали, "пока ты спал"©
Дык ведь тут ваш коллега сказал, что в ORM сложную обработку данных делать неудобно и неэффективно. После этого для чего нужен ORM стало для меня загадкой.
