Здравствуйте, BVA, Вы писали:

B>>Согласен. Тем более, что заплесневелая "система прав" идёт из лохматых 70-ых, когда о трёхзвенках и не слышали! (а потому лепили "пермишены" прямо в БД)
B>>Апп.сервер даст стократ более гибкий И УДОБНЫЙ метод разграничений, чем все эти пляски с ролями, схемами, правами и т.п.

BVA>Пермишны на уровне БД полезны даже при наличии трехзвенки. Это повышает трудозатраты на взлом системы

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

Здравствуйте, Baiker, Вы писали:

B>Вопрос: насколько полезным вы находите эту фичу и используете ли её вообще? Как часто в проектах вам вот требуется scheme?

Я ещё раз прочитал весь топик. Ребят, извините все, кого задел сованием "префиксов", немного сложно перестроить мышление, если никогда схемами не пользовался Итак, понятно — схемы нужны и важны! Даже не с позиций прав, а хотя бы "отделить своё от не своего".
Т.к. оригинальный вопрос был в контексте управления БД через ГУЙ, возникает следущий вопрос:

КАК ИМЕННО вы работаете со схемами? Прям вот ежедневная рутина. Вы выбираете одну схему и в ней торчите весь день? Вы работаете сразу с 2-3 схемами? Удобно ли иметь тупо плоский список таблиц и фильтровать его по схемам? Это не вопрос, как вы ПИШЕТЕ SQL запросы — я про общую работу в каком-нть менеджере. Чего нехватает для удобства работы со схемами?
Черкните пару строк, если не лень. Типа "в Прога1 сделано так, а мне удобно, чтобы вот так".

Вот там, где я говорил про "дерево навигации", это было про Maestro — тоже графический тул, но в гробу я видал прыгать по его деревьям... Если с двумя схемами я ещё разберусь, то распахивать дерево для десяти схем — это уже полный маразм и потеря производительности.

Здравствуйте, Baiker, Вы писали:
B>Тут надо откатиться назад и вспомнить, что речь про программистов и БД — это вообще не их компетенция "взлом базы". Не говоря о том, что если хацкер поимел доступ вообще к базе, пермишены по схемам уже мало чем помогут.
Это не совсем так.
Грубо говоря, у вас с одной базой может работать несколько сервисов.
И если в одном из них обнаружилась уязвимость типа SQL injection, то при использовании "root access" на всю базу (а то и кластер) вы дадите злоумышленнику возможность утащить вообще всё.
А раздача прав на уровне хотя бы сервис:схема всё же даст изоляцию "отсеков" вашего авианосца друг от друга.
Скажем, сервис, который трекает отзывы клиентов о вашем банке может быть делегирован нубасам, которые вообще ни в зуб ногой в правильных техниках — и даже если его сломать, то максимум что получит злоумышленник — сломает рейтинги. А доступа к данным банковского ядра (обработке транзакций) он так и не получит.

То есть безопасность — это небинарная величина, типа "нет физического доступа базе" либо "есть физический доступ к базе".
Гораздо чаще реальная уязвимость расположена где-то посередине этого спектра, и изоляция её последствий всё ещё позволяет минимизировать ущерб.

Здравствуйте, Baiker, Вы писали:

B>КАК ИМЕННО вы работаете со схемами? Прям вот ежедневная рутина.
Visual Studio + SQL Server Data Tools. Отдельный проект под БД.
Структура верхних папок такая же, как в SSMS. Внутри каждой есть папка со схемой, внутри схемы уже сами объекты.
Например:
./Tables/sec/users.sql — таблица sec.users
./Tables/sec/clients.sql — таблица sec.clients
./Tables/billing/payments.sql — таблица billing.payments
./Programmability/Stored Procedures/sec/getUserByID.sql — хранимка sec.getUserByID
...
Сами схемы определены в папке ./Security/Schemas/.

Можно и по другому структуру папок создать, но мне так удобнее/привычнее, а остальные ребята в команде не настоящие DB-лы и будут делать так, как я сказал.

B>Вы выбираете одну схему и в ней торчите весь день? Вы работаете сразу с 2-3 схемами?
Я работаю с функционалом. Т.е., с work item, user story, to-do item — как хочешь назови.
В общем, мне надо обеспечить какой-то кусок функционала приложения.

Соответственно, я работаю со всеми объектами во всех нужных мне схемах, чтобы этот функционал обеспечить.
Это может быть одна схема, может быть и десяток — не важно.

B>Удобно ли иметь тупо плоский список таблиц и фильтровать его по схемам?
В целом, мне удобна структура, которую я привёл выше + поиск по имени/части имени объекта. Было бы удобно ещё иметь поиск по коду, отфильтровывающий список файлов, как это сделано в VS Code, но и без него терпимо, в общем-то.

Правда, ты не циклись на таблицах так, т.к. что с ними-то работать? Один раз определил, да пару раз доработаешь, как новый функционал потребуется, да и всё. Больше работать будешь с DML, чем с DDL, ИМХО.

B>Если с двумя схемами я ещё разберусь, то распахивать дерево для десяти схем — это уже полный маразм и потеря производительности.
Чисто ИМХО — в этом убожестве в принципе работать маразм и потеря производительности. Сужу чисто по скриншотам, но как в этом говне работать, я не представляю. Там же невозможно работать с БД как с кодом...

Здравствуйте, Baiker, Вы писали:

B>Тут надо откатиться назад и вспомнить, что речь про программистов и БД — это вообще не их компетенция "взлом базы".
Это большое заблуждение.
Безопасность — это компетенция, размазанная по всем командам, замешанным в создании и эксплуатации продукта.

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

B>Ну и третий момент, знания по DBA. Далеко не все программисты могут "залезть и поменять права" на какую-то таблицу или схему.
А и не надо разработчику в БД лезть и менять права.

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

B>Меньше всего я хочу прыгать в отладчике кода "почему я не могу получить список городов" только из-за того, что где-то в БД небрежный товарищ забыл добавить прав.
Меньше всего, всё же, ты, наверное, хочешь потерять работу и получить плохую репутацию только из-за того, что тебе было лень предусмотреть в своём коде разграничение прав и на уровне БД в том числе и злоумышленник получил доступ сразу ко всему инстансу СУБД, т.к. ты попросил прав сисадмина для логина своего приложения, а потом случайно написал код, позволяющий банальный SQL Injection.

А попрыгать в отладчике на этом фоне так — мелочи жизни, поверь.