baracsЛПbaracs
И если клиент читает/меняет данные в БД через хранимые процедуры, это:
- во многих случаях, сильно ускоряет работу системы в целом,
- упрощает обеспечение целостности и непротиворечивости данных,
- сильно упрощает сопровождение и развитие системы;
- про разделение доступа к объектам бд тут уже много писали...
В случае, если у СУБД ровно один клиент (а это именно случай многозвенных приложений) - Ваше высказывание неверно по всем пунктам (по некоторым пунктам оно неверно и в случае многих клиентов)
А поподробнее?
А чего подробнее то?

Про скорость работы переобсосано миллион раз. Использование хранимок может дать как увеличение скорости работы (за счет отсутствия необходимости компиляции плана выполнения), так и уменьшение скорости (за счет того, что этот самый гвздиками приколоченый план не учитывает изменение входных параметров и изменившуюся статистику низлежащих данных).
Однозначного выигрыша от использования ХП нет ни для случая одного клиента ака средний слой, ни для многих клиентов ака классическая двузвенка.

Обеспечение целостности и непротиворечивости данных - так оно вообще не с помощью ХП делаться должно. Нормализация, констрейнты - да, упрощает обеспечение целостности и непротиворечивости. Обеспечивать целостность хранимками - нет, не упрощает, только усложняет. Причем если обеспечивать целостность SQL-кодом, то нет разницы, где этот код расположен, в хранимке на сервере, или в теле программы в одном единственном клиенте (ака средний слой). Одинаково неудобно.

Аргумент "упрощение сопровождения и развития" - для одного клиента неверно. Для многих клиентов - верно (проще сопровождать код на одном сервере, чем на многих клиентов), а для одного - нет (что на одном сервере код сопровождать, что на одном клиенте).

Те же самые соображения в ответ на аргумент "разделение доступа к объектам". Что рулить доступом к объектам на одном единственном сервере, что рулить доступом к объектам на одном единственном клиенте - нет разницы.
Вернее, разница есть, и она не в пользу хранимок.
Рулить доступом к объектам на клиенте я могу любым удобным мне способом. Любым. Удобным. Мне.
Чего нельзя сказать про управление доступом к хранимкам и прочим объектам на сервере БД.

2 locky
А можно более подробно, что в вашем понимании есть "клиент"
В контексте предыдущего обсуждения "клиент БД" = "средний слой многозвенки"
Доступ, соответственно, к объектам этого же самого среднего слоя (до объектов БД конечного пользователя никто и не допустит в обход среднего слоя).

2 pkarklin
Если Вы про Domain, Entity и прочая, то да, это делается декларативным способом, но существует еще ограничения бизнес-логики, например, клиент не может оформить заказ на условиях предоплаты на сумму более 5 000 руб, если у него еще нет выполненных заказов на условиях предоплаты на общую сумму не менее 25 000 руб.
Не спорю.
И такие ограничения бизнес-логики можно придумать, что реализовывать их на T-SQL - весьма тоскливое занятие. Одна из причин для "посмотреть в сторону многозвенок". Или какого-нибудь унылого говна с офигенно развитым внедренным в СУБД супер-мега-пл-т-эскюэль

Есть, и принципиальная. Система, в которой прямой доступ к таблицам закрыт, а вся работа организована через вьюхи и хп является самодостаточно устойчивой (про права админа не будем, ибо против лома нет приема). А в Вашей схеме, если код, обеспечивающий целостность данных, расположен в одном клиенте , то другой клиент , не содержащий такого кода, подключившись к бд может привести ее в неконсистентное состояние.
Товарисч pkarklin, Вы вообще как, внимательно сообщения читаете, прежде чем на них отвечать берётесь?
Какой такой другой клиент, если русским по белому и неоднократно сказано, что клиент для БД - один единственный?

А почему он у Вас "один единственный"?!
По определению. По начальным данным диалога с baracs. Потому что других клиентов пристрелили из ружья.

Чем это гарантируется, или, наконец, что может помешать подключиться к базе другим клиентом?!
Вам подсказать способы, как не дать другим подключиться, или сами додумаетесь?
Думаю, что сами справитесь. Я в Вас верю.

Опять, 25. Но это не значит, что не любимый и не удобный лично Вам способ не существует и дает целый ряд преимуществ.
То, что существует удобный лично мне способ - вовсе не означает, что не удобный мне способ не существует. Я нигде такого и не говорил. В чем Вы меня пытались убедить - не понял.
Неудобный (не самый удобный для меня) способ - разумеется существует. Для данной конкретной СУБД существующий неудобный способ может быть единственным. Для кого-то другого (для каких-то других задач) этот способ может быть вполне хорошим. А мне то до этого какое дело, если этот кому-то для чего-то удобный способ - не подходит мне и для конкретной задачи?

Безусловно, этого нельзя сказать, если не знаешь, как это делается. ;) Ибо реализация ACL (включая row & cell level security) на стороне реляционной СУБД делается не просто предоставлением (или не предоставление) доступа к тому или иному модулю с кодом в бд, а чуть сложнее.
Это уже детали, к чему именно и какую именно секьюрити надо обеспечивать. В трехзвенке, BTW, эти детали вообще мало волнуют мозг. Чего не скажешь об.

lockyКак ДБА, скажу.
Любителей размазывать sql код по приложению - надо стрелять грязным тапком.

Правильно.
Любителей размазывать логику по приложени ям (кусок кода в СУБД, кусок кода где-то еще, в WCF-сервисе каком-нибудь) - стрелять двумя грязными тапками, и контрольный выстрел нестиранными трусами.

Только не думайте, что приложение перестает быть приложением только от того, что крутится в том же процессе, что и MS SQL Server (к примеру)
:)

lockyЛП,

уточню.
Любителей выносить код sql за пределы SP - стрелять мокрыми тряпками.
Типо хп - эт не приложение вовсе, а так, насрано.
Понятно :)

2 pkarklin
А то как насмотришься, как некоторые на апп. сервере и джоинить пытаются и прочая, получив плоские наборы с сервера СУБД, дабы реализовать ТАМ ограничения целостности или секьюрность, то волосы дыбом встают.
Угу. А как посмотришь на курсорные трактора внутре хранимок - что дыбом должно вставать?
Оно канешн на каком-нибудь расширении SQL, и аж внутре хранимки лежит, и за это этому унылому говну можно простить его внешний вид :)

Не надо меня возить мордой по столу по топику.
Надо. Если Вы с первого раза не понимаете, то как еще.

Это не Вы ли продекларировали:
Я. Какое-то слово непонятно?

Будем снова перетирать про быстродействие и удобство сопровождения, раз уж Вы упомянули только про некоторые пункты?!
Перетирать идите мух с котлетами в мясорубке.
Я ясно высказался, что высказывание barack неверно по всем пунктам в случае одного клиента, и по некоторым - в случае многих клиентов.
Яснее - не умею.
Пусть кто-нибудь другой попробует объяснить Вам разницу между "один" и "много", и между "все" и "некоторые".

Влез в этот тред тока с целью предостеречь неокрепшие умы читающих его от апологетов "логики на клиенте" (фокспро\аксесс форева!!!).
Вы дурак, простите?
Где Вы увидели фокспро/аксес?
Вам что-то приглючилось, и Вы решили предостеречь неокрепшие умы от Ваших собственных глюков?
Когда протрезвеете - приходите, может удастся пообщаться.

Вы так делаете?! Кмк, мы тут перетирали про код на клиенте или в хп, а не и.
Нет. Так делают (собираются делать) некоторые другие участники этого обсуждения.

Поддержу Вас в Вашем демогагическом начинании, а программа на ASM - это приложение для процессора, а процессор - приложение для материнской платы и т.д. и т.п. Самим Вам не смешно?!
Не, не смешно.
За размазывание логики про приложению на АСМе - тоже стрелять тапком.
Я серьезен как никогда. Демагогии - ноль.
Когда-нибудь поймете. Как протрезвеете.

2 barrabas
это как раз произойдет если вынести её на среднее звено, а тут окажется что нужен триггер или джоб.
Ума не приложу, зачем может понадобиться триггер, если логика обработки данных вынесена на средний слой :)
Ну да и ладно.

А если есть задачи которые к базе отношения не имеют и к клиенту тоже
О, это вообще не сюда - что-то ни к чему не относящееся. Ему ни хранимки не помогут, ни отсутствие хранимок не помешает. Программирование фотошопа этажом выше.

раз в в базе и на клиенте ей делать нечего и это не повод
Это не повод называть это нечто средним слоем.
Не называйте это "ни к чему не относящееся" средним слоем - и ни малейших возражений не получите на свои высказывания. Правда невелика будет и ценность этих высказываний в контексте обсуждения "хранимок в трехзвенке"