Petro1231.
a) давай код с данной проблемой. Которая поставит БД раком. А также версию данной БД. Могу свой Оракл на сайте открыть для тестов.
б) Дальше то, что не сгущай краски о том, что один коннект повесит всю СУБД (какую именно?).
Учитывая то, что 2-х звенка пишется в _локальной_ сети.
а) На . И это не проблема, это возможность, которую можно использовать в обход ПО.
б) Я не сгущаю краски, а пишу реальные вещи. Один коннект ничего вешать не будет, речь о том, что в руках злоумышленника (а такой обязательно найдется на предприятии из 10 тыс душ) открытая оперативная БД для всего домена - геморрой на заднее место. Даже элементарный чайник может написать батник, который в цикле дергает БД и что-то возвращает, тем самым просаживая перформанс и отклик сервера баз данных. Вообщем, если дырка есть (а она есть), туда обязательно кто-то насрет. Кто этого не понимает, пусть дальше пишет двухзвенки, я не против.

Petro123не люблю слова "любых".
Это твои проблемы, что ты там любишь.

Petro123Все китайцы тоже на одно лицо, пока не займёшься конкретным проектом.
Не понял, о чем ты. Но, наверное, о чем-то умном.

Petro123Не шарик вкорячивается в ХП, а Шарик - делает запросы в СУБД.
Шарик не делает запросы в СУБД, он вызывает серверную объектную модель (несколько видов объектной модели есть, включая серверную и клиентскую). А сама модель уже обращается в БД. Так вот расскажи мне, как в случае двухзвенки с логикой в хп ты будешь обращаться к ферме шарепоинта? Я пока сбегаю за попкорном.

LSVПользователь может зайти на SQL сервер в обход программы, например через Management Studio.Ну тут можно придумать ряд мер, чтобы пользователь не знал реальный логин-пароль. Это не есть проблема.
Это проблема. Через любой дизассемблер (родной WinDbg, как вариант) я могу снять конечную строку соединения в момент физического соединения с СУБД.

Petro123МСУДаже элементарный чайник может написать батник, который в цикле дергает БД
банальную дос-атаку мы не рассматриваем. Ддосить можно всё - от сайтов до родителей))
Извини, дос сайта - это пустяки, по сравнению с оперативной базой, содержащая важнейшие бизнес данные, с которой работает не только твоё кривое двухзвенное ПО .

Petro123МСУродной WinDbg, как вариант
win авторизация через AD, как вариант
Какой же это вариант, при аутентификации AD еще проще снять строку соединения, чтобы соединиться с СУБД.

Petro123МСУа) На . И это не проблема, это возможность, которую можно использовать в обход ПО.
расшифруй где проблема?
Говори русским языком, я тебя не понимаю. Что расшифровать, строку соединения? За 5 минут я отладчиком через бряки отдизассемблирую код и сниму реальную строку соединения (тип string). Ты об этом?

Petro123Если ты написал ХП без управлениями транзакциями внутри, то:
- a) где злой код?
- б) ты сам написал код внутри ХП без возможности отката при любой ошибке (нет rollback)
- в) в 3-х звенке можно написать так-же
а) Злой код не внутри, а снаружи.
б) Ты читаешь каким местом то, что я пишу? Какая хранимая процедура? Я тебе говорю о внешний запросах, которыми может оперировать пользователь, который подсоединился к СУБД.
в) Каким местом?

Petro123Если данные настолько важны, то делают N-звенки и даже часовых у входа.
Видимо, защищают данные и распределяют к ним доступ.

Petro123Если эти данные вроде НСИ для всего предприятия или планирование, то и 2-а звена пойдут.
Не вижу логики. Если деньги тебе так важны, храни их на чердаке, а не в за тремя стенами в банке.

Petro123Главное, что делить данные по Важности обязательно надо. И это делает заказчик, а не ты.
Делить тебе ничего не надо, предоставь заказчику надежную распределенную систему. А что хранить там будут, тебя не касается.

Petro123Т.е. Линейка решений, а не линия партии от MS.
Убил своей нелинейной логикой наповал... Комментировать нечего.

Petro1232. Конечно, где надо вин-аутентификация, а где не надо - обычная
Как это относится к обсуждаемому вопросу? Не вижу разницы, с помощью какого метода конечный пользователь соединится с БД. Вся проблема в том, что у него есть эта возможность. А это очень плохо.

Petro123а) чем BEGIN TRAN снаружи (клиентский) грозит? Процедуру в слое API нужно писать атомарную и неделимую.
в) в сервисном слое в 3-х звенке тоже есть BEGIN TRAN. Да, пользователь его не напишет, но тогда возврат к вопросу о том - чем он грозит.
а) Ты не в курсе, "чем грозит" открытая транзакция? Ну сходи в школу, там расскажут. Сама процедура ничего не знает о её внешних потребителей, да и не должна знать. А тут приходит левый пользователь и начинает творить страшные вещи с этой хранимой процедурой, оборачивая её в транзакции, играясь с её параметрами и т.д. Ты считаешь это нормой? Чем дальше спрятана БД от сторонних глаз, тем выше надежность. Или ты будешь с этим спорить?
б) То, что есть в сервисном слое - спрятано от пользователя. Есть только конечные методы, ака interface. Пользователь не сможет ничего сделать, кроме как вызвать этот метод. Он не может выполнить что-то своё, какой-то свой SQL запрос или инъекцию. Только метод. А в случае двухзвенки, у пользователя 100% возможности SQL, которым он может оперировать прямо в боевой базе на продакшене. Разница есть?

ВМоисеевДавайте уважать друг друга, не надо упрекать коллегу в незнании, или в том, что он не так строит системы. Давайте рассматривать плюсы-минусы альтернативных подходов. Беда не в том, что не знаешь, а в том, что не хочешь знать.
Вова, не насилуй мне мозг, я больше всего терпеть не могу вот эти детские сопли по поводу уважения, упреков и прочих ми-ми-ми. Есть тема, есть участники, есть дискуссия. Есть что сказать - пуляй, обжуём и подумаем. Нет ничего по теме - сиди, вникай. Ничего личного.

Petro123что страшного в параметре дата?
Ничего.

Petro123что страшного в begin tran?
http://www.sql.ru/articles/mssql/01072301causesofsqltransactionlogfillingup.shtml Читай пункт 2: При наличии в журнале незавершённых транзакций: журнал транзакций может быть усечен только до самой старой незавершённой транзакции. Есть несколько возможных причин появления незавершённых транзакций, большинство из которых относятся к ошибкам прикладного программного обеспечения.
Транзакция будет препятствовать усечению и других более коротких транзакций, которые исполняются в то же самое время. Пока пользователь соответствующим образом не отреагирует, приложение не сможет исполнить COMMIT, а усечение журнала не будет возможным. Ну и далее по тексту.


Petro123тебе дать логин от моей? Страшно подумать что ты там наделаешь без прав от меня
Читай выше, надоело повторяться.

Petro123Т.е. ХП в СУБД с грантами - это API или твой сервисный слой.
Гранты грантами, но у пользователя есть свобода действий в виде SQL, а это очень плохо и вредно. Имея прямой доступ к БД появляется уникальный шанс исследовать хранилище в целях поиска узких мест, чтобы рано или поздно подломить БД. Или ты уверен, что пишешь код, который 100% безопасен и который нельзя сломать? Я сомневаюсь в этом. Сервер приложений как-раз таки минимизирует подобные риски. Самое страшное, что можно себе представить, - это получить полный доступ ко всему хранилищу. Так вот в двухзвенке ты уже делаешь замечательный подарок атакующему - прямое соединения с оперативной БД во всём домене. Счастье ли? Или будешь дальше спорить о том, что ты пишешь 100% валидный безопасный код и учитываешь все варианты исхода событий? Даже не смешно.

Petro123а в общем случае я с тобой согласен - чем дальше ключи от квартиры тем лучше)
О чем и речь.

ДжекНепотрошительОпытный матерый пользователь всегда имел консольку, в которой он правил данные как раз SQL-запросами :)
Это еще нормально, а как тебе открытая dbf на шаре, доступ к которой есть у всех пользователей? :)