Зачем нужен LDAP ???

ты не понимаешь ЧТО такое ldap, а ЧТО такое mysql. рекомендую почитать документацию на то и другое. а отвечать на твой вопрос в том виде, в каком он задан сейчас - бессмысленно.

Я знаю что такое mysql и примерно представляю себе, что такое LDAP.

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

Но в mysql можно хранить большие объёмы данных (например логи), можно выполнять запросы по хранящейся информации (например считать статистики).

А в LDAP запросов нет.

Вот я и не понимаю, зачем в этом случае нужен LDAP?

Честно говоря у меня тоже возникал такой вопрос, когда я впервые столкнулся с ldap-ом, ответа я так и не придумал. Может я чего-то не понимаю, но на мой взгляд ldap это та же СУБД, только менее гибкая (например из-за того, что в подключаемых схемах обязательно должны быть элементы с конкретными OID (даже в RFC написано), в то время как в СУРБД обязательное наличие каких-либо полей в таблицах не требуется). Тем более, что ldap в качестве backend-а использует опять же обычную БД. Т.е. ldap - это переходник между запросами к нему и запросами к БД, который позволяет не привязываться к конкретной СУБД. Хотя, если сравнивать его возможности с возможностями этих СУБД, то это не будет являться преимуществом.

P.S. Все написанное - мое личное мнение, если я не прав - готов его пересмотреть :-)

В общем, я согласен с мнением товарища sasha999, но все-таки попробую ответить, только просьба не обижаться!

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

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

Если нужно складывать логи с потового сервера, больше подойдет SQL.

А если, сделать единую базу пользователей для всех сетевых служб предприятия/организации, то - LDAP.

LDAP позволяет разнести пользователей по подразделениям, и независимо от этого объединить в группы, гибко раздать права на объекты и поддеревья пользователям/администраторам, ну и т.д. и т.п. В то время как в SQL базах все это нафиг никому не нужно.

openldap обычно использует berkeley db, за счет чего достигается выигрыш в производительности на задачах требующих большого количества запросов на чтениею

О!
Уже горячее :).

Но, с другой стороны то, что есть в LDAP, можно сделать в SQL (объединение в группы, права доступа и т.п. вполне можно сделать в БД). А вот то, что есть в SQL, сделать в LDAP ой как сложно (те же запросы).
Т.е. не соревнование кастрюли и сковороды, а сковороды и блинопечки.
В первой можно жарить всё, что угодно, а во второй - только блины.

Давай рассмотрим конкретный пример из жизни (мой).

Есть почтовый сервер, который поддерживает несколько доменов.
Есть БД, в которой лежат все пользователи + настройки доменов и ящиков + туда же падают выжимки из логов. Там же лежат настройки для доменов, из которых генерируются файлы настроек для bind.
Есть веб-морда для редактирования этой информации из БД.
Есть генератор отчётов из этой БД.

Если я меняю SQL на LDAP, то на мой непросвещённый взгляд вылезает куча минусов:
1). Лишняя сущность. Всё, что есть в LDAP, можно сделать в SQL; как тут уже сказали, LDAP всё равно хранит информацию в БД.
2). Непонятно, насколько быстро это будет работать с большими объёмами информации (допустим, что кол-во пользователей вырастет до ~100000).
3). 2 хранилища (LDAP для мелочи + SQL для больших объёмов) вместо одного (SQL для всего).
4). Неоднородность доступа. Сейчас один запрос SQL вытаскивает всю нужную мне статистику по всем пользователям. Если делать на LDAP, то придётся писать обход всех объектов-пользователей из LDAP (?).
И т.п.

И пока только один плюс (спасибо han'у): возможность более лёгкой раздачи полномочий.

В то же время народ дружно переходит с SQL на LDAP. Значит в нём что-то есть. :)
Вот я и спрашиваю, в чём же плюсы LDAP.

Люди, ну приведите же конкретный пример из вашей практики (без сковородок ;) ), когда LDAP был бы действительно удобнее SQL.
Я верю, что в какой-то ситуации он удобнее, но пока не вижу такой ситуации.

Спасибо.

> openldap обычно использует berkeley db, за счет чего достигается выигрыш в производительности на задачах требующих большого количества запросов на чтениею

IMHO в БД можно насоздавать индексы, специально заточенные под запросы, что (теоретически) будет работать ещё быстрее.

В ldap есть мощная поддержка репликаций в распределенных системах. в mysql ничего подобного нет.

> в mysql ничего подобного нет
Хорошо, а если не ограничиваться только mysql-ем ? :-)

Не надо заострятся только на этом. LDAP есть LDAP. Сравнивать его c MySQL нельзя, потому что бессмыслено. Это разные сущности, несмотря на то, что в чем-то их можно использовать с одиноковой сущностью. LDAP --- это система каталогов. SQL --- система запросов. (упрощено). Вы же не сравниваете NDIS или AD с MySQL, правда?

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

С использованием LDAP для адресной книги возражений нет.

Но сравнивать LDAP с MySQL можно и нужно хотя бы потому, что области их применения пересекаются (как минимум для хранения аккаунтов/настроек).
Иначе первоначальный вопрос не возник бы.

А по поводу использования LDAP в качестве хранилища настроек возникает впечатление, что LDAP выгодно использовать только в случае распределённой огрструктуры с кучей админов и серверов (простая раздача полномочий, репликация, распределённое хранение информации).

Т.е. в моём случае (один админ, 1-2 почтовых сервера) переход на LDAP ничем не оправдан?

Задумайся об значении аббревиатуры LDAP. Это "_протокол_ _доступа_". По каким критериям можно это сравнивать с "_языком_ _запросов_"(sql)? Это ортогональные сущности. Можно реализовать LDAP доступ к SQL БД. Можно к не-SQL. Первый вариант чреват боком. Почему? Почитай у openldap про backend-sql.

То что области их примения пересекаются, говорит лишь о том, что в случае с MySQL пытались приделать к корове седло.

> То что области их примения пересекаются, говорит лишь о том, что в случае с MySQL пытались приделать к корове седло.

"То что области их примения пересекаются, говорит лишь о том, что в случае с LDAP пытались приделать к корове седло."

Аргументы какие-нибудь будут? Или всё как обычно - на чистых эмоциях?

Спасибо, буду читать...

LDAP это кусок выдранный из X.500 по-моему. И предназначено это для организации возможности доступа к "иерархически-организованной" информации. OID нужен для того-же, для чего он нужен и в SNMP. Для того, чтобы приложения, которые работают с LDAP "знали" к какому типу данных сейчас они обращаются.

По большому счету разница в том, что реляционные базы данных имеют плоскую стуктуру, хранятся в одном месте и легко доступны через sql запросы, а ldap предназначен для поиска чего угодно в распределенном каталоге. Поясню: есть 10-20 и более серверов, которые должны хранить одну и ту же базу и иметь возможность ее редактировать, выдавать клиентам информацию по любому объекту, независимо от того, на каком сервере объект был добавлен. Такая база данных не плоская, а имеет распределенную древовидную структуру. Для поиска именно в ней и применяются ldap запросы. Кроме того, для подключения клиента к sql серверу нужно учитывать особенности конкретной реализации сервера, например, клиент MySQL не подключится к Oracle и наоборот. А ldap - универсален, использует стандартный порт, независимо от его реализации (openldap, AD, Lotus Domino etc.) любой клиент легко подключится и будет нормально работать с ним. А как хранит сам ldap сервер внутренние данные - это его дело. Общий итог таков - нужно хранить данные и анализировать их - используем sql сервер; нужно иметь распределенную базу данных объектов какой-либо структуры и простой механизм поиска - используем ldap.