2 softwarer
Большинство ваших возражений против "все через ХП" выглядят как "всегда есть ситуация, когда без ХП будет ничуть не хуже". И с этим нельзя не согласится.
И я полностью согласен с тем, что работа через ХП в принципе не быстрее. Что строить фильтрацию черех них - громоздко и неудобно.
Кстати,
2 igorolv
авторДело в том, что конструкция "x.ID = @ID or @ID is null" оптимальнее, чем x.ID = isnull(@ID, ID). Так как некоторые оптимизаторы(MSSQL2005) в ДАННОМ КОНКРЕТНОМ случае "подменяют or на union".
Вы сами-то проверяли данное утверждение? На 4-5 условиях OR? Или это надежда? :) ИМХО, насколько я помню, декларировалось только, что оптимизатор МОЖЕТ это делать в некоторых случаях)
Но вот с последним утверждением я не согласен
авторНа практике оказывается, что такое разбиение в целом соответствует объектам раздачи прав [не знаю, как бы это удачно сформулировать]; если в администрировании предусмотрены элементарные роли A, Б и В (элементарные - то есть не содержащие других ролей), то разбиение на А.dll, Б.dll и В.dll в большинстве случаев будет неплохим выбором
Элементарное разбиение на права - это в общем случае, может быть разбиение до операций. Т.е. в примере locky - как раз те самые 400 модулей, по документу в модуле. Насколько это оправдано технологически - не мне вам обьяснять.
Предположу больше - ХП практически всегда больше, чем функциональных модулей на клиенте. Возможно, вы найдете какой-то хитрое исключение из вашей практике, но это будет именно исключение. Отсюда следует, что изменение одного модуля на клиенте затронет больше функционала.
Я вовсе не призываю становится по знамена "все только через ХП". Однако, как мне кажется - в большинстве "обычных" клиент-серверных систем, наиболее эффективным является сведение SQL кода на клиенте к простейшему минимуму. Т.е. выведение любых более-менее сложных запросов либо через ХП, либо через view.
Отдельной строкой здесь стоят ИС, поддерживающие различные серверные платформы, но там требования совместимости перевешивают все остальное.



Nobody faults but mine... (LZ)

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

авторЭто оправдано куда как больше, нежели 400 документов в одном exe-шнике ;)
При столь подробных входных данных, сами понимаете, трудно судить об оптимуме.
Как вы любите писать " я легко могу представить обратный пример..." :)
В самом деле, здесь могут быть самые разные ситуации и один ехе-шник на 400 документов - не похож на оптимальное решение. Но, для большинства случаев, в предположении хотя бы минимального наследования - иметь даже одну библиотеку мне кажется несколько более эффективным, чем 400 отдельных.

авторЭто несколько бессмысленная фраза, имхо. Для иллюстрации удобно воспользоваться оракловым понятием пакета
Я недостаточно знаком с оракловым понятием пакета; фраза о функционале возникла в предположении что одна ХП выполняет одну функциональную операцию (отчет, проводка и т.п.) В более сложных ситуациях, этих ХП может быть несколько, но предполагаем что время прописывания всего этого пакета невелико и им можно пренебречь. В тоже время функционал одного модуля - опять же, как правило, для большинства случаев - содержит несколько функциональных операций, пусть даже связанных. Следовательно, его замена в среднем может оказать более критична/неудобна.
Еще раз хочу подчеркнуть - поскольку требования на разработку могут быть практически сколь угодно фантастическими, поскольку решаемые ситуации могут быть просто непредсказуемыми, я пытаюсь рассуждать о неком обширном пласте "обычных" ИС. С более-менее типовыми задачами.
Отдельно хочется заметить - ваше рассуждение о том
авторчем ниже технологический уровень изделия, тем более оправдана унификация и наоборот, чем выше требования к качеству результата, тем тщательнее нужно подходить к каждой детали.
конечно, правильно, но... если надежность изделия (причем любого) сильно зависит от тщательности обработки его каждой детали, надежность выпуска таких изделий невысока. В приложении к этому спору - заранее отказываясь от любых ограничений в используемых программных решениях (там - ХП, сям - обработка на клиенте, а здесь вообще 3-й слой) мы можем получит большую эффективность, но она сильно будет зависить от опыта конкретного разработчика. Как мне кажется, такой подход удобен при разработке маленькой командой; для более крупных отделов - довольно опасно.

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

авторТогда мы ставим под угрозу целостность БД.
В общем случае - согласен
авторПоэтому приведу простой пример - если это расчет, не требующий немедленных действий, скажем отчет о дебиторской задолженности, выгонять пользователей ну совершенно необязательно
Довольно странно - почему-то для ХП вы сразу предполагаете угрозу целостности БД. (правильнее, впрочем целостности функционала). А для клиента допускаете что эта угроза может быть необязательной. А с моей точки зрения обе описанные вами ситуации ну ничем абсолютно не различаются.
Точно также можно предположить, как из незамененного клиентского модуля уйдут на сервер 2% вместо 20%, и точно также, что эта ХП возвращает отчет по дебиторской задолженности.





Nobody faults but mine... (LZ)