Sergey SА как решаются вопросы производительности?
К примеру сейчас есть одна программа по расчету премии - тут задействована своя с-ма бюджетирования
Конечный результат выводится в excel-ий файлик для каждого филиала по 4 листа разных таблиц - это все выдается несколькими процедурами, строится довольно быстро, т.к. вся логика сидит в процедуре и выполняется на хорошем сервере...
Если загнать логику в клиента.... нада попробовать.... скажите кто примерно такого уровня сложности (не сильно простую) логику пробовал - нормально будет?
И начать рекомендуете с NHibernate или просто в своих объектах логику заложить?При правильном применении Linq2Sql отличие в производительности от варианта на хранимых процедурах будет минимальным, а в некоторых случаях даже быстрее.

ViPRosSergey S,
какая еще сложность при расчете премий?Насчитать себе нужную сумму, чтобы никто не заметил. :-)

netivanАлексей К,

но все же она не на все способна, к сожалению.Её его возможности в последнее время весьма активно развиваются. Уже имеющихся возможностей вполне достаточно. Недостающие возможности ( вроде рекурсивных запросов ) легко выносятся во View в БД.

В итоге имеем в сервере приложений сопоставимые с хранимыми процедурами возможности + все возможности C# и его библиотек. Что как минимум позволит работать с данными из разных БД, веб-сервисов и т. п. Если даже сегодня это не надо, в дальнейшем такая необходимость весьма вероятна. Пусть кому-то удобно "по-старинке" иметь логику в ХП, но решение с логикой в LINQ на сервере приложений, как минимум, тоже имеет право на жизнь.

По некоторым параметрам LINQ несколько удобнее SQL, взять те же ассоциации vs join, let vs вложенный запрос и т. д. Хотя и недостатки тоже есть. Истина как всегда где-то посередине...

МСУДалеко на такой "логике" не уедешь. Размазня без ООП - это не логика, это линейный лапшекод :)Линейный лапшекод лучше ООП-лапшекода. Его проще разгребать. Так что тут тоже нужно без фанатизма. :-)

МСУАлексей КЛинейный лапшекод лучше ООП-лапшекода. Его проще разгребать. Так что тут тоже нужно без фанатизма. :-)
Если у нас десяток строк кода, то соглашусь. Не доводилось работать с хранимыми процедурами под 1000 строк и более? Причем их таких несколько штук под конкретную "задачу", примерно одинкаковых по смыслу. И за отсутствием наследования, прилодилось писать вспомоготальные общие хранимки, которые нужно было вкорячить в те десять. Бррр, накую такую "бизнес-логику" Видимо MSSQL? Там да, с этим хреново, нет пакетов, "как в Ёракле" :-)

МСУОпять двадцать пять :) Не нужно концепцию оракуля перекладывать на сиквел, не нужны сиквелу пакеты.Нужно. Чтобы не было 100500 хранимых процедур с дикими префиксами в именах, чтобы хоть как-то можно было в них ориентироваться.

МСУДа и сам пакет не решит ничего в разрезе наследования, просто перекладывание гавна по кучкам, не более того.Сущности наследовать можно во вьюхах через select * from . Полиморфизм - а нужен ли он тут?

МСУМСУНе доводилось работать с хранимыми процедурами под 1000 строк и более? Причем их таких несколько штук под конкретную "задачу", примерно одинкаковых по смыслу.

Да, Алексей, самое главное - как насчет документирования такого "кода"? :)Рефакторить надо. Производить "выделение метода" по Фаулеру.

МСУАлексей КНужно. Чтобы не было 100500 хранимых процедур с дикими префиксами в именах, чтобы хоть как-то можно было в них ориентироваться.
А вот нечего плодить такой говно-зоопарк. А то понаплодят гумна, а потом там еще и ориентироваться нужно.А что делать, пакетов-то нет. Приходится плодить. :-) Отсутствие пакетов - одна из причин, почему мы отказались от логики в MSSQL в пользу сервера приложений.
МСУКстати, тема пакетов в сиквеле - баян.Я в курсе. :-) Просто удивляет упорное нежелание Microsoft их делать. :-)
МСУВ топку пакеты.Нет! :-)
МСУАлексей КСущности наследовать можно во вьюхах через select * from . Полиморфизм - а нужен ли он тут?
Мне страшно представить, что у тебя потом там с планом выполнения запросов будет, когда ты понагородишь огороды "наследования".Оптимизатор запросов MSSQL порой просто творит чудеса. Большой респект от меня его авторам. Вы ещё наши запросы, рожаемые EF, не видели. :-) И ничё, планы выполнения мало отличаются от рукописных запросов, несмотря на обилие лишних вложенностей и прочего мусора.
МСУDBA кастрирует.Я как-то рассказывал, с какими админами приходится иметь дело. Так что не кастрирует. :-) Все планы выполнения по возможности оптимизируются разработчиками на этапе разработки/опытного внедрения. DBA в этом участия не принимают.
МСУВо-вторых, наследование через вьюхи - это просто жесть :)"На безрыбье и рак рыба" (с) :-)
МСУВ-третьих, наследование нужно не только в отображении, но и во внутренней логике (например, расчет зп, отпусков, увольнений и т.д. - какие в жопу вьюхи?). Полиморфизм нужен, Леша, нужен.Я не против. :-) Просто нам пока не требовалось.
МСУАлексей КРефакторить надо. Производить "выделение метода" по Фаулеру.
Причем тут рефакторить? Я спрашиваю о документировании всего этого безобразия. Неужели о чем-то невообразимо нереальном вещаю? Вот уйдет твоя команда обезьянок, придут новые - начинаем с перелопачивания и изучения кода по камментам? :)Ну сначала рефакторить, потом документировать. В противном случае вариантов кроме коментариев внутри процедур не вижу. Зато сэкономили на разработке, эффективный менеджмент, хуле... Работает да и ладно, и нечего туда лазить. :-)