LDAP vs DB

вопрос то должен быть не где хранить, а как использовать. Вот когда поймете, как использовать, так вопрос «где хранить» отпадет.

Ну как использовать. Определять доступ к тем или иным подсистемам автоматизированных систем организации. Делать отчёты, включающие в себя персональные данные людей. Создавать новые горизонтальные связи (вроде: персоны X, Y и Z участвуют в одном проекте, при этом персона X играет в этом проекте роль руководителя).

Хотелось бы немножко расширить вопрос, а зачем, вообще хранить пользователей в ldap? Из-за возможности использовать общие аккаунты для систем, которые разрабатываете сами, и для систем, которые купили у других?

Как минимум, у нас авторизация происходит через ldap, точнее, через AD.
Я с ldap-ом очень давно последний раз плотно общался, и забыл уже всю теорию, что в нём хорошего, и что в нем плохого :(

Хотелось бы немножко расширить вопрос, а зачем, вообще хранить пользователей в ldap?

Для каждого сервиса заводить отдельные учетки? У нас как минимум 8 сервисов из ldap юзеров тянут.

оргструктуру (вертикальные и горизонтальные связи, точнее говоря)?

атрибут «manager» есть, так что.... почему бы и нет?

Ты, кстати, не сможешь в одной транзакции изменить данные и в субд, и в лдапе.

Атрибутов можно добавить, если уж стандартных схем совсем не будет хватать :) Хотя когда я этим плотно занимался, мне казалось, что в стандартных схемах предусмотрено всё возможное и даже невозможное.

Не смогу, и это ещё один плюс за «всё в ldap». Впрочем, это не наш случай, у нас аудитория... единицы сотен человек - это с запасом. То есть потенциальная аудитория несколько тысяч, но актуальная - единицы сотен.

Дык в стандартной схеме есть почти все нужные атрибуты, в т.ч. manager.

Иногда правда приходится изгаляться (например мы для skype логина используем атрибут audio).

Хм. А можно ли настроить схему на хранение multi-language data? У нас вся информация имеется в двух вариантах, русском и английском/латинице.

Системы, которые будут определять доступ уже написаны? Генераторы отчетов? Системы ведения проектов? Они у вас ldap поддерживают? Насколько гибко?

Потому что если нет или недостаточно гибко, и при этом нормально поддерживают sql или что у вас там за db... то смысл?

Плюсы LDAP'а в его стандартизации, в жесткой модели данных, которой придерживаются end-point software.

К примеру если заполнить атрибутами типа Имя-Фамилия и т.п. записи - то скормив LDAP доступ почтовому клиенту можно получить адресную книгу.
Скормив его же какой-нибудь системе - получить имена и фамилии пользователей вдобавок к их авторизации. Или их состояния в группах. И так для кучи ldap-enabled ПО. Поставил, изменил фильтр выборки атрибутов, пошел дальше.

А можно ли настроить схему на хранение multi-language data?

Вопрос без привязки к определению этой data для ldap не имеет смысла.

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

Э... ещё раз?

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

Имена, адреса, названия - всё такое.

Под это дело можно перевести всё что угодно на всё что угодно.

Перевод ради перевода не имеет смысла.

Я бы в общем сказал, что в LDAP можно пихать все, что очень часто нужно (сотни и тысячи запросов в секунду), но очень редко меняется.

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

Как использовать данные, полученные от LDAP сервера - решает клиент.
Сила LDAP в том, что много клиентов запрашивает, получает и использует данные каталога одинаковым способом. И если ты будешь придерживаться распространенных моделей хранения и использования данных - ты получишь совместимость с большим количеством стороннего ПО.

В то время, как в SQL каждый сам за себя.

если ты будешь придерживаться распространенных моделей хранения и использования данных - ты получишь совместимость с большим количеством стороннего ПО

Понятно, спасибо, в голове прояснилось. Похоже, это всё-таки не наш случай. Ещё и мультиязычность...

Если у тебя только один, свой клиент, который ты же и пишешь - то не проблема. Поля вроде имен-фамилий-названий multi-line. Я например в этих полях первым всегда указываю один язык, а вторым - второй. Но это не стандартная модель использования, поэтому стороннее ПО отрабатывает по этим полям кто как придется.

А вот адрес нет. Ты можешь сам посмотреть определения полей в схемах LDAP.

Но это не стандартная модель использования

Поэтому смысла в ней нет.

В принципе стоит.

Во-первых, это редко меняющиеся данные, а ldap для таких данных и создан.

Во-вторых, ldap удобен для расширения схемы, добавления новых аттрибутов и т.п.

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

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

Когда начнёшь обильно обрастать различными сервисами не пожалеешь.

Вот дааа, группы, пожалуй, стоит туда вытащить...

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

А почему, можешь развернуть мысль? Почему-то все советуют использовать LDAP именно для данных которые меняются редко..

Потому что основная операция в каталогах это чтение. По этой причине реализации LDAP затачивались на чтение, а не на запись.

Затачивалась на чтение в плане производительности? Мне казалось, что ЛДАП по производительности сильно уступает многим СУБД, разве нет?

ldap берёт не производительностью, а удобством. Не надо строить таблицы. Не надо делать триггеры, внешние ключи, заморачиваться со всем этим. Ты просто говоришь - люди это записи, у которых (objectClass=organizationalPerson), а департаменты - это записи, у которых (objectClass=organizationalUnit), а должности - это атрибуты людей, которые (objectClass=organizationalRole). И оно само проверяет на правильный objectClass, оно само поддерживает множественность значений атрибутов, и всё остальное.
Это каталог. По нему нельзя сделать отчёт, аналитику, ещё что-то хитрое. В нём можно найти то, что требуется, и сделать это легко и просто, даже проще, чем в sql. Ну и классика жанра - авторизация. Не надо солить пароли, шифровать, что-то куда-то класть... Просто авторизуем учётку в каталоге. Если авторизивался - хорошо, значит пароль правильный.

Примерно то же самое можно сделать в какой-нибудь nosql базе, например в монге, правильно? То есть ЛДАП удобнее тем, что у всех записей стандартизованная структура (objectClass, uid и т.д.), с которой работает большинство софта?

Не надо строить таблицы. Не надо делать триггеры, внешние ключи, заморачиваться со всем этим.

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

Да вроде не сильно глубокая там задница, насколько я помню.

Помимо прочего LDAP и производительностью на чтение берет - сложные запросы могут быть быстрее за счет другой модели хранения данных. А вот с записью у него плохо (в том числе, как правило, забудьте про ACID).

Ну какой acid. Это же каталог. Картотека. Не более.