Алексей КCat2Ну, матом не крыл, но "идиотами" или неким подобным обзывал
Это же просьба относится ка Алексею К.

Бывалоча начнется дискуссия, я бы еще чего мог сказть - ан нет. МСУ и Алексей поцапались и тему закрыли.Вы что-то путаете. Мы с МСУ никогда не ругались. Все наши с ним дискуссии всегда были в рамках приличия.
Прошу прощения. Они с SeVa ругаются

Получить может. Соединится не может.
МСУНа пальцах еще раз: в двухзвенной архитектуре пользователь ПО может безпрепятственно получить строку соединения к БД (пусть даже если ты строишь ПО с помощью виндовой аутентификации в БД). Ты считаешь нормальной практикой, если юзеры (пусть даже особо продвинутые или не очень) начнут хаотично юзать БД через сторонние клиенты (Excel, Access, Management Studio и пр.), делать большие выборки, ковыряться во внутрях БД и искать узкие места? Уже сам факт возможности попадания пользователя в БД, тем более сторонними средствами - вопиющ и опасен. Я уже не говорю про двухзвенки, в которых строка соединения к БД идет от sa либо от достаточно привилегированной сиквельной учетной записи - за такое вообще расстрел на месте.
Cat2, что не понятно по безопасности? Вопросы, комментарии, замечания приветствуются.

Получить может. Соединится не сможет, если его виндовой группе не предоставлено право на доступ к конкретной базе.

Впрочем, могут быть более мягкие варианты. Например, все Domain Users включены в группу public одной из баз. В этом случае они могут увидеть названия таблиц. И все.

Никакого доступа из Excelя не получится, если доступ дается не через разрешения на иаблицы, а через разрешения на ХП.

Разумеется, если используется ОРМ, то кому-то будут даны прямые права на таблицы и можно будет, при известных знаниях, лазать к базе чем угодно.

При использовании хранимых процедур пользователи не знают их названий и не знают их параметров.

Но даже если и знают, то не смогут сделать ничего того, что не позволдяют сделать хранимки.

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

MasterZivИначе выигрыш только в удобстве оформления кода, проигрыш в привязке к конкретной субд.
Вы постоянно пишете приложения которые должны работать со всеми существующими СУБД?

MasterZivCat2Не все можно сделать с клиента хорошо.
Например, транзакции.


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

MasterZivCat2Хранимые процедуры всегда будут чуть быстрее, так как они уже откомпилированы и для них обязательно создан план запроса.


Это сильно зависит от СУБД.
Подготовленные запросы также во многих СУБД откомпилированы.
Планы некоторые СУБД кэшируют и для простых запросов, а не только для процедур.
Не все запросы простые.

MasterZivKorbanz,

В общем, подытоживая, могу предложить следующий "решатель" проблемы.

если надо использовать CRUD -запросы (CreateReadUpdateDelete) и у тебя не одна поддерживаемая СУБД, стоит использовать ORM.

Если надо писать только аналитические запросы (SELECT-ы ) то ORM применять бесполезно

если поддерживается только одна СУБД, стоит писать код в виде хранимых процедур. если поддерживается одна-две СУБД, можно тоже писать код в виде хранимых процедур, несколько раз, для каждой СУБД свой вариант. Естественно, только если процедур немного (10-20).

если запросов много, и много поддерживаемых СУБД, (и запросы аналитические, естественно), то лучше подумать о оформлении кода SQL на клиенте напрямую на SQL в виде универсального, стандартного SQL-я, иногда это получаться не будет, тогда надо писать конкретный запрос в N вариантах, для каждой СУБД.

Не согласен ни с одним пунктом.

Алексей КИмею самописный несложный кодогенератор, удобный для дальнейшей поддержки и модификации.
+1 тоже