ViPRosзайди в БД и замени key на GUID
А если полить бензином сервер с БД и поджечь, работать будет?
Странное занятие, так просто менять типы в хранилище. Найми себе хорошего проектировщика DBD и освободи свою жизнь от создания схемы данных.

P.S. Сахават, хватит откровенно гнать. Уже не смешно.

EnomayМСУ Но так или иначе, самое ценное в ORM - это типизация хранилища, как следствие родной человеческий интелиссенс, с которым одно удовольствие работать. Рутинные же SELECT FROM WHERE в прошлом.


на самом деле самое ценное в ORM - это возможность работать с объектами, а не строками в таблицах. это существенно при использовании ООП.

Ну а я что сказал?

зыДанила, проснулся и сразу в бой :)
Если бы :) С работы приехал, все праздники похерились...
зыЗачем мне рассказывать о том, чем я не занимаюсь?
Ок. Просто меня смутило, как ты стал открещиваться от олапов.
зыЭто же уже обсудили, нужно было перечитать топ вначале, раз отстал на пару страниц.
Хм, вроде всё прочитал. Видел предложили штатными средстами разрулить, я предложил более гибкий DLINQ - вещь!

Пойду-ка я спать, завтра зайду - чую зы ответную херачит на пергаменте

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

зыИногда быстрее и эффективнее написать решение конкретной проблемы, не стараясь заложить в неё все возможные юскейсы, подстилки и прочую бутафорию. Это все стоит денег и отнимает время, а на конкуретном рынке нет ни того ни другого.
Стоп. Никто просто так закладывать такие возможности не будет. У одной компании при внедрении нашего софта - Oracle, у другой лицензия MS SQL, у третьей DB2. А теперь представь себе потери, если мы заложились только под сиквел.
Система вида корпоративного документооборота + биллинговые педали со всевозможными вытекающими. Как правило, в биллинге обычно оракуль, в документообороте сиквел или оракуль. Опять будешь говорить - ситуация надуманная?

зыВозьми вконтакт, например. Даже имея предмет прямого копирования, они занимались с самого начала такой ерундой, как полная абстракция от хранилища данных? Да они бы таким образом не взлетели.
Возьми, например, 1С, Documentum, SAP, ... Эти системы не завязываются на один вид БД. Они смотрят вдаль и в свой кошелек.

зыЗачем переходить с oracle на mssql и обратно?
Выше всё объяснил.

зыЗабыли, что понадобится новая фича, которая есть в другом сервере? Или лицензия закончилась? Или разница между ними в +500% производительности на тех же данных с теми же запросами?
Насчет фичей - придется обломиться. Либо написать отдельные плагины для таких фич. В качестве архитектурного подхода рекомендую рассмотреть MEF. Загружай фичи конкретной СУБД и радуйся. Если без этого никак.

зыДа поверь, на проде в безобидных местах под нагрузкой начинались такие необъяснимые финты с пулом и прочими внутренностями, что пришлось в срочном порядке выпиливать нафиг, благо он там не сильно нужен был. Я конечно не уверен в идеальной прямости рук программистов, но я уверен в том, что это достаточно умные люди.
Ну мы щас говорим о средней температуре по больнице. Никакой конкретики и сути. Что-то там было, а что было - фиг знает. Ну сам понимаешь, ничего сказать не могу тут. Могу погадать, разве что, на кофе :)

зыНа форумах коммьюнити встречались такие же случаи, но без ответа. Хибернейт — это очень большой и очень черный ящик. А, как известно, надежность систем уменьшается с возрастанием их сложности.
Ну кто ж тебя так хибером напугал, зы? ;) Не бойся ты так. Всё там стабильно работает, данная ORM не первый год замужем.

зыфантазирую о чем? уточни
Обо всём, что я зацитировал.

зы1) зачем писать свой балансировщик для монстра, если можно просто поднять скорость выкинув монстра? все дело в конкретной проблеме. Тем более что ты говоришь об этом, как будто описанная тобой задача - как два пальца обоссать.
2) да, кэшировать в БД, чтобы быстрее делать выборки из БД — это самое оно.
1. А в чем сложность его написать? Можешь вообще в отдельном облаке хостить свои кеши.
2. Не для больших наборов, только для общего хранения. С сессией тоже так сделать можно, не написав строчки кода.
3. Кстати, чем не нравится вариант кеширования на каждой ноде в кластере? Вообще ни строчки кода.

зыЯ не знаю, может под .net его как-то упростили или недоделали, что ты в нем так уверен, он ведь из явы пришел. Ну и не нравятся аргументы — пожалуйста, кушай наздоровье, я ж не настаиваю
Ну если не знаешь, зачем в спич полез? )

зыбожеж ты мой, зачем ты приплел сюда OLAP и полностекст? я тут 11871560 привел конкретный пример.
Как зачем, ты ж сам первый начал.

авторпревосходно, но это же вставка чистого SQL без проверок в compile time :) не нужно себе противоречить, и раз уж допускаешь исключения, то допускай их везде, в том числе на самом высоком уровне — в подходе.
Ты же сам захотел динамику - поэтому без проверки. Типизированной динамики не бывает

зыя просто боюсь сложных вещей, если я вижу что-то сложное, мне сразу кажется, что это можно сделать проще.
Реально, кроме шуток, скачай себе последний хибер, открой пару блогов для стартапа и создай тестовый проект на чистом hbm. Проникнись хибером пару тройку дней. Обещаю, тебе очень понравится этот инструмент. Потом копни глубже, покури разные там флюенты, HILO, сложные мапы типа hierarchy mapping, сложные детачи и критерии, кастомные subquery с кастомными трансформаторами и иже. Хибер - это вещь.

зыМСУ, это мишура, фантики, доп.опции для авто. Обычно хочется всего и сразу, просто потому что оно есть и доступно.
В том-то и дело, что ORM - это всё и сразу. Но дело твоё.

зылучше использовать ORM или работать напрямую? Правильный ответ — "не знаю", потому что у абстрактного вопроса задача так же абстрактна. Но ты подсознательно формулируешь для себя новый вопрос "нравится ли мне работать напрямую? — нет. Нравится ли мне ORM? — да", и отвечаешь, что нужно использовать ORM полюбому, хотя уже исходный вопрос был заменен.
Да, нужно использовать ORM полюбому. Только так. Даже для тех же мемкешей есть свои порты в виде отдельного провайдера.