Рекомендации по моделированию LDAP

Question

Я очень настроен на реляционное моделирование, но плохо знаком с моделированием LDAP и ищу лучшие практики для проектирования схем LDAP. Хотелось бы узнать, каковы эквиваленты третьей нормальной формы и других практик в мире LDAP?

Ссылки на официальные документы по этому вопросу приветствуются.

Answer 1

Выберите стандартную схему, такую ​​как core , косинус , inetOrgPerson , eduPerson , Java-объекты, и т. Д. в соответствии с вашей целью. Большинство серверов LDAP имеют набор значений по умолчанию.

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

Answer 2

Наш опыт показывает, что дизайн схемы и DIT очень зависит от назначения сервера LDAP.

Для этой схемы, как правило, лучше придерживаться "стандарта" промышленного производителя или сервера LDAP.

Для структуры DIT, если только она не предназначена для файловой службы и службы печати (т.е. Active Directory) или OES (Netware), тогда, как правило, «плоская» структура масштабируется лучше.

Если это большая реализация (т. Е.> 100 тыс.), Тогда следует избегать групп, если это возможно.

-Джит

Answer 3

Исходя из моего опыта, я могу максимально денормализовать, поскольку целью, как упоминалось ранее, с LDAP является очень быстрый поиск, но это означает, что вставка записей может занять больше времени через некоторое время. Также важно убедиться, что вы можете хранить резервные копии ldap.

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

Посмотрите, что, вероятно, понадобится. Например, в университете, в котором я был, мы поняли, что некоторые люди, которые только косвенно имеют отношения с университетом, будут иметь учетную запись LDAP.

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

Если вы собираетесь разрешить пользователям входить в систему с их учетной записи Unix, то в схеме должны быть определенные классы.

Answer 4

LDAP по своей природе НЕ совместим даже с первой нормальной формой - некоторые ее атрибуты могут содержать несколько значений.

LDAP - это система, разработанная для оптимальной производительности чтения / просмотра, например, это более уместно в сценарии, когда вы будете читать / искать данные более, чем изменять их (-> каталоги; телефонная книга вашей компании не будет меняться десятки раз в день).

LDAP не предназначен и не предназначен для замены или конкуренции со стандартной системой реляционных баз данных, которая отлично справляется с вводом / преобразованием данных, когда большое количество ваших операций будет вставлять и / или обновлять данные. Вот для чего СУБД идеально подходят.

Итак, в заключение: LDAP vs. RDBMS на самом деле не являются началом, и эти два мира совершенно различны и совершенно различны по своему стилю работы. Я бы не советовал пытаться слепо применить что-то из одного мира в другой - это будет плохое совпадение.

Что касается вдохновения для разработки схемы LDAP - я бы определенно посмотрел на Active Directory от Microsoft, eDirectory Novell (или как это называется в наши дни) и, возможно, на другие каталоги LDAP, и учился на их проектах.

Марк