> Спасибо за ответ.
>> LDAP DIT - это расширенный key-value, где для ключей определена иерархия, а
>> value состоит из набора обязательных и опциональны атрибутов.
> да, но сформиулирую так - можно ли как-то сделать, чтобы KEY был
> лишь контейнером для других KEY?
> со множественностью проблем нет это я понимаю (один ключ может повторяться сколько
> угодно, в соотв. со схемой конечно), а вот такая вроде бы
> нехитрая система с вложенностью - сколько ни гуглил такого не видел. Не уверен что могу понять что вы имели в виду, кроме как предположив что речь о составных ключах и/или индексах.
В LDAP это не обязательно, т.е. не требуется для соблюдения RFC (хотя их много и я точно не читал все). Соответственно, вы не можете рассчитывать на подобные возможности глядя на абстрактный LDAP-сервер.
С другой стороны, в (Re)OpenLDAP доступно определение составных индексов по атрибутам, в том числе с контролем уникальности. Плюс есть всяческие плагины/оверлеии типа MemberOf и виртуальных групп.
>[оверквотинг удален]
> | -- тут key - value (выполнивший)
> | | |
> | | -- имя выполнившего - Иванов
> | | |
> | | -- должность - прораб
> | -- тут key - value (номер договора какой-нибудь)
> ...
> Данные поступающие то вроде по большей части как раз иерархические, так что
> в качестве "фронта" вроде логично использовать не табличное хранилище. Но насколько
> тут приспособляем LDAP я пока не очень пойму...
И так тоже можно..., но насколько удобно решайте сами.
Также нужно не забывать, что LDAP не гарантирует ACID на уровне всего DIT, а только для отдельных элементов.
> Может есть какие-то качественные ссылки, где люди описывают опыт не стандартной работы
> со схемами? Был бы благодарен.
https://pro-ldap.ru/
Только смотреть/искать нужно не чей-то опыт, а вникать в возможности сервера, через примерны понимать как их настраивать, а затем (желательно) понимать как это работает внутри.
