kryak Надо ли ее продумывать на уровне проектирования или лучше это сделать только на хранимых процедурах SQL и средствами я зыка программирования.

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

Я строю защиту в двух направлениях: доступ к функциональным режимам системы и доступ к участкам данных.

Функциональные режимы обычно отражены в управляющем меню. Отсутствие доступа к режиму означает отсутствие соответствуещей закладки меню у этого пользователя. Он вообще может не знать о том, что такой режим существует.

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

tru55Защита данных, как я понимаю, сильно зависит от БД. Например, в Oracle могут применяться пользователи, гранты, view, синонимы, доступ к данным через хранимые процедуры и т.д.

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

Ввод в таблицы выполняется из интерфейсного модуля. Не хорошо вынуждать пользователя работать со средствами администратора БД. Главбух может добавить пользователя, дать ему роль, допустить до конкретных режимов работы, бухгалтерских счетов и т.д., при этом главбух не имеет понятия, что такое SQL Server.