Я очень хорошо разбираюсь в реляционном моделировании, но новичок в моделировании LDAP и ищу лучшие практики для разработки схем LDAP. Хотелось бы узнать, каковы эквиваленты третьей нормальной формы и других практик в мире LDAP?
Ссылки на технические документы, раскрывающие эту тему, приветствуются.
Выберите стандартную схему, например ядро, косинус, inetOrgPerson, eduPerson, объекты Java, и т. д. . подходит для вашей предполагаемой цели. Большинство серверов LDAP поставляются с набором значений по умолчанию.
Отдайте предпочтение существующим элементам, но если вам нужно расширить схему, добавьте префикс comCompany (доменное имя вашей компании или другой уникальный идентификатор), чтобы избежать конфликтов с будущими стандартными элементами.
Наш опыт показывает, что структура схемы и DIT сильно зависит от назначения сервера LDAP.
Для схемы, как правило, лучше всего придерживаться «стандарта» отрасли или поставщика сервера LDAP.
Что касается структуры DIT, если только она не предназначена для службы файлов и печати (т. е. Active Directory) или OES (Netware), то, как правило, «плоская» структура лучше масштабируется.
Если это большая реализация (т.е.> 100 КБ), то групп следует избегать, если это возможно.
-Джим
Исходя из моего опыта, денормализуйте как можно больше, поскольку цель, как упоминалось ранее, с LDAP — очень быстрый поиск, но это означает, что через некоторое время вставка записей может занять больше времени. Также важно убедиться, что вы можете хранить резервные копии ldap.
Однако вы можете рассмотреть возможность создания различных классов, таких как пользователь, но также иметь класс для пользователя авторизации, если это необходимо.
Посмотрите, что, вероятно, будет необходимо. Например, в университете, в котором я учился, мы поняли, что некоторые люди, имеющие лишь косвенное отношение к университету, будут иметь учетную запись LDAP.
Когда вы определите, какие типы пользователей или ресурсов будут в ldap, это поможет вам определить, как настроить людей. Например, если у вас есть один класс, который представляет собой только имя пользователя или идентификатор и пароль и, возможно, сертификат, то это было бы полезно для гибкости.
Если вы собираетесь разрешить людям входить в систему со своей учетной записи unix, то в схеме должны быть определенные классы.
LDAP по своей сути НЕ совместим даже с первой нормальной формой — некоторые из его атрибутов могут содержать несколько значений.
LDAP — это система, предназначенная для оптимальной производительности чтения/поиска, например. это более уместно в сценарии, когда вы будете больше читать/просматривать данные, чем изменять их (--> каталоги; телефонная книга вашей компании не будет меняться десятки раз в день).
LDAP не предназначен для замены или конкуренции со стандартной системой реляционных баз данных, которые превосходны при вводе / преобразовании данных, где большое количество ваших операций будет вставлять и / или обновлять данные. Именно для этого РСУБД идеально подходят.
Итак, в заключение: LDAP и RDBMS действительно не являются стартовыми, и эти два мира совершенно разные и совершенно разные по своему стилю работы. Я бы не рекомендовал пытаться вслепую применять что-то из одного мира к другому — это будет плохое совпадение.
Что касается вдохновения при проектировании схемы LDAP, я бы определенно посмотрел на Active Directory от Microsoft, eDirectory от Novell (или как там это сейчас называется) и, возможно, на другие каталоги LDAP и поучился бы у них.
Марк
