Почему компании не используют LDAP в качестве центрального хранилища для других пользователей?

Question

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

Microsoft Active Directory делает обширные расширения схемы, но лишь немногие коммерческие продукты используют возможности LDAP.

Это потому, что большинство разработчиков LDAP не знают, как моделировать за пределами пользователей? Найти ценность в этом, но просто не задумывались об этом? Пробовал и столкнулся с проблемами производительности? Что-то еще? L

Answer 1

• Я всегда думал, что LDAP был слишком высокий уровень для сетевых администраторов и слишком низкий уровень для разработчиков программного обеспечения. Кажется, никому из них это не нравится.
• Существует мнение, что, поскольку почти каждое корпоративное приложение будет использовать реляционную базу данных, добавление еще одного источника данных снижает доступность и надежность приложения.
• Барьер для создания пользовательских схем в LDAP по-прежнему высок. На серверах LDAP вы должны поместить файл схемы в каталог схемы, обычно с привилегиями root или администратора, чтобы перезапустить сервер LDAP; тогда как текущие ORM могут создавать, обновлять или проверять схемы реляционных баз данных при запуске приложения.

Answer 2

Лично я считаю, что LDAP - это каталог , а не база данных. Каталоги хороши для поиска людей и связанных с ними данных, но они не особенно хороши для отслеживания сильно реляционных данных - именно так выглядит большая часть остальных наших данных. На самом деле, мы используем LDAP как интерфейс для данных о людях, объединяя множество потоков данных в одно представление каталога. У нас все еще есть данные о людях в базах данных базы данных вместе с остальными нашими институциональными данными, и мы выбрали только LDAP (в нашем случае ADAM) в качестве внешнего интерфейса для удобного поиска объединенных данных о людях. Теперь, когда мы переходим к веб-службам в качестве средства доступа к этим данным, я не уверен, что даже имеет смысл продолжать движение по маршруту LDAP (за исключением поддержки существующих служб, которые не были обновлены).

Answer 3

Мы выполнили работу для некоторых компаний с 65 миллионами записей LDAP, ни одна из них не была предназначена для людей.

Данные представляли собой различные элементы, в основном для устройств, включая: * DHCP * DNS * Mac адреса * Место нахождения * SN * Бренд * Модель * и т.д ....

-Джит

Answer 4

Я бы подумал, что это связано с А) сложностью работы с LDAP (намного выше, чем с SQL) и Б) тем фактом, что ваш продукт будет полностью привязан к нему. То есть у него не было бы рынка за пределами крупных организаций, работающих с LDAP. За меньшие деньги и усилия я мог бы создать приложение, которое будет работать где угодно.

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

Answer 5

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

Реляционная модель и ее выражение в SQL - мощная вещь. Я не думаю, что это будет легко вытеснено LDAP или объектными базами данных.