Использование сервера LDAP в качестве базы хранения, насколько это практично?

Question

Я хочу узнать, насколько практично использовать сервер LDAP (скажем, AD) в качестве базы хранения.Чтобы быть более понятным;Насколько имеет смысл использовать сервер LDAP вместо использования СУБД для хранения данных?

Я могу предположить, что большинство из вас могут просто сказать «это не так», но могут быть некоторые причины, чтобы сделать это осмысленным (особенно для бизнеса);

Сначала несколько точек;

• Каждая таблица становится контейнерной сущностью, а каждая строка становится новой сущностью в качестве дочерней.Строка сущностей содержит атрибуты для столбцов.Таким образом, вы представляете свои данные таким образом.(Это должно быть наиболее значимое представление, я думаю, предложения приветствуются)
• Таким образом, хранение данных, таких как сервер БД, возможно, но проблема заключается в отсутствии поддержки FK и PK (не уверен в PK).С другой стороны, он поддерживает индексирование атрибутов (относится к столбцу) (не уверен, насколько эффективно).Таким образом, согласованность данных является ответственностью прикладного уровня.

Зачем кому-то делать это когда-либо?

• Данные, которые приложение использует / хранит, близко соответствуют существующим данным в AD,(Пользователи, машины, информация об отделе и т. Д.) (Но все же некоторая настройка требуется для существующей схемы объекта, и новые определения схемы необходимы для не очень связанных данных.)
• (я думаю, что самая веская причина была бы в этом: связанные с бизнесом) Большинство компаний среднего размера имеют очень хорошо настроенные серверы AD (реплицированные, резервные копии и т. д.), но у них нет такой настройки БД (вы можете комментировать это сколько угодно).Скажем, когда вы продаете свое программное обеспечение, которое требует настройки БД, этим компаниям, они должны управлять настройкой БД;но если вы скажете «вам не нужны настройка и управление БД; вы можете просто использовать существующий AD» , это звучит привлекательно.

Очевидно, что отказ от использования БД имеет много недостатков, не стесняйтесь упоминать их, но давайте предположим, что они приемлемы.(Я могу упомянуть больше, если вопрос недостаточно ясен.)

Answer 1

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

Подумайте о типичных отношениях один-ко-многим - скажем, о клиентах и ​​заказах. У одного клиента много заказов.

Нет хорошего способа представить эти данные в каталоге LDAP.

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

Вы можете попробовать создать объект "customer", у которого есть дочерние объекты "order". Однако вы только что ввели определенную иерархию - теперь вы привязаны к ней.

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

Если вы храните телефонную книгу, тогда обязательно используйте LDAP. Для всего остального используйте реальную базу данных.

Answer 2

Для относительно небольших, гибких наборов данных я думаю, что решение LDAP работоспособно. Однако СУБД предоставляет ряд существенных преимуществ:

1. Резервное копирование и восстановление : практически любая база данных предоставит ACID свойства. И резервные копии СУБД, как правило, просты в написании сценариев и предоставляют несколько вариантов (например, полное или разностное). Просто не знаю с LDAP, но я думаю, что эти качества не так широко распространены.
2. Отчетность : AFAIK LDAP не позволяет легко объединять значения, тем более, например, вычислять суммы. Таким образом, вы приложили бы много усилий к коду приложения, чтобы воспроизвести эти варианты поведения, когда вам действительно нужны отчеты. А какое приложение не в конечном итоге?
3. Индексирование : похоже, что решения LDAP имеют индексацию, но, опять же, кажется, что это хит или мисс. Принимая во внимание, что, казалось бы, все базы данных приложили некоторые реальные усилия, чтобы сделать это правильно.

Я думаю, что хранилище любой серьезной бизнес-системы должно создаваться таким же образом, как вы считаете, LDAP в большинстве сред. Если вам действительно нужны гибкость в плане представления иерархии и способности определять динамические схемы, я бы посоветовал взглянуть на решения NoSQL или репозиторий контента Java.

Answer 3

Ответ на самом деле прост.Подумайте о CRUD ( C reate, R ead, U pdate, D elete).Если в вашей системе будет много чтения, вы можете подумать об использовании LDAP.Потому что LDAP быстр в операциях чтения и разработан так.Если другие операции будут сделаны больше, RDMS будет лучшим вариантом.

Answer 4

Если бы я был на вашем месте, я бы предпочел одно из решений NoSQL db, а не пытался использовать LDAP.LDAP подходит для таких вещей, как хранение информации о пользователях и сотрудниках, но ужасно взаимодействовать, когда вам нужно внести изменения.NoSQL db позволит вам хранить ваши данные так, как вы хотите, без лишних затрат на СУБД, которых вы хотели бы избежать.

Answer 5

Короче говоря: используйте правильный инструмент для правильной работы.

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

С помощью «базы данных каталогов» вы можете создавать приложения определенного типа. Если вы можете сопоставить свои данные с древовидной структурой, это будет работать. Я, конечно, не хотел бы, чтобы пара видео от LDAP! Возможно, вы можете что-то взломать, но я бы предпочел парящий сервер ..

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

Это не , а не просто техническая проблема . Ваша группа оперативной поддержки может «нахмуриться» на ваше приложение, поскольку у них будут определенные ожидания / предубеждения, основанные на архитектуре вашего приложения. Представьте себе их удивление, если вы предоставите им систему CRM (веб-сайт + файлы, отправленную электронную почту и т. Д.) На сервере LDAP в качестве базы данных для обслуживания.

Answer 6

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

Я использовал этот подход для развлечения, я создаю телефонную книгу из Active Directory, но яНе думайте, что стоит использовать LDAP в качестве хранилища для бизнес-приложений.