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

В системе регистрируются преподаватели.
Вопрос: какой вариант грамотнее:
1. При входе в систему преподавателя анализируются его
регистрационные данные и соответствующим образом настраивается фильтр на его данные

2. В базе существует справочник преподавателей
и фильтр настраивается по данным этого справочника

В системе периодически появляются новые поьзователи (преподав),
для которых фильтр также должен быть настроен.
Один преподаватель может работать на нескольких кафедрах.

Вопрос снимается. Я разобрался.

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

Таким образом, для каждого пользователя на клиенте
в Grid попадают только его данные, т. е. происходит фильтрация
данных по UID.

Вариант заменить ряд строчек одним словом :)

...Так или иначе, по своей сути отсечение ряда записей (совокупности таблиц), в целях получения их подмножества, удовлеворяющее ограничению на атрибут (в данном случае UID) это есть процесс фильтрации

На АРМ администратора происходит регистрация
преподавателя (хранимая процедура также передает
UID в пользовательскую таблицу и доп. информацию о
преподавателе).

Таблицы, содержащие данные, требующие фильтрации,
имеют в своем составе атрибут UID

Когда преподаватель начинает сеанс, его идентификатор
доступен через USER_ID().
Таким образом, для разных преподавателей
USER_ID() возвращает свой ID, который и передается
на вход ХП.

Прошу прощения отдельно за каждую замороченную голову.

USER_ID() действительно используется внутри
хранимой процедуры

Разницы особой не вижу будь то регистрационная инфа пользователя в ОС
или же регистрация на уровне SQL сервера. В любом случае создаются
в SYSUSER UID, которые передаются в пользовательскую таблицу для
дальнейшей обработки.

Сама процедура добавления login и user + передача UID реализована
на АРМ админа (т. е. существует собственное приложение администрирования,
одна из функций которого добавление и удаление пользователя)

Предполагается, что разрабатываемая система функционирует периодически.
Период работы длится 1 год (планирование осущ. на 1 год), затем база
архивируется (промежуточные backup не исключаются) и подготавливается к новому сезону.

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

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

А кривые ручки жили, живут и будут жить, резервные копии!!! гарантия успеха

Осознаю, что вариантов может быть много, но пока остановились на варианте:

1. Регистрация на уровне ОС контролирует сотрудников института (доступ к информационной сети)
2. Регистрация на уровне SQL сервера контролирует пользователей,
владеющими данными в БД или обладающие возможностью их создать

На мой взгляд при таком подходе повышается уровень безопасности.
Зав. каф. отслеживает всех преподов своей кафедры и если кто-то уходит
нужно оценить оставшийся объем нагрузки, пререраспределить ее.

На это нужно чуть чуть времени. (Если учет фактической нагрузки велся не полностью или вообще не велся к примеру), а тут мы сразу раз и удаляем его.
Чтобы в течение этого времени ушедший сотрудник не пользовался благами
общей сети мы его вырубаем на уровне операционной системы, но на время оставляем на уровне SQL сервер.

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