Мне интересно, разумна ли идея использовать Active Directory для хранения сущностей, связанных с приложением, когда не все типы сущностей являются традиционными сущностями AD, такими как организационное подразделение, пользователь, группа и т. д.
На данный момент у меня есть схема базы данных, состоящая из таких вещей, как клиенты и пользователи. У каждого клиента могут быть свои отделы. Каждый отдел может иметь набор пользователей. У каждого пользователя может быть имя, данные аутентификации и т. д. Коллега напомнил мне, что в Active Directory уже есть инфраструктура для поддержки такого рода иерархий, поэтому перестраивать ее с нуля может быть неоптимально.
Теперь моя проблема в том, что мне понадобится гораздо больше сущностей, чем просто клиенты, пользователи и так далее. Мне придется хранить статистику, документы, контакты (которые не являются пользователями в sysetm) и другую информацию. Чтобы выбрать число из воздуха, может быть 10-20 дополнительных типов объектов, которых еще нет в Active Directory. Эти типы сущностей будут «связаны» с клиентами, пользователями и т. д. Пользователи в этой системе не являются пользователями моей локальной сети, но будут иметь доступ к моему программному обеспечению через Интернет.
У меня очень смутное представление об Active Directory, но, насколько я понимаю, мне придется расширить схему AD для хранения своих собственных сущностей. Мне нужно было бы добавить свойства в «Организационное подразделение», например «список документов».
Альтернативный метод может состоять в том, чтобы полагаться на организационные подразделения, пользователей и группы в AD и иметь отдельную базу данных MSSQL для хранения оставшихся данных. Моя база данных MSSQL затем должна была бы связать такие объекты, как «контакт», с конкретным подразделением или пользователем, используя его уникальный идентификатор или как бы он ни назывался.
Есть мысли по этому поводу? Целесообразно ли хранить сложные типы в AD, а не в базе данных MSSQL?
(Скорее всего, объектов достаточно мало, чтобы в любом случае производительность не была проблемой)
