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

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

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

первые несколько пунктов;

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

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

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

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

6
database ldap

6 ответов

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

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

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

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

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

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

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

7

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

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

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

1

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

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

0

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

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

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

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

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

0

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

0

ответ на самом деле прост. Думаю КРУДА (Create,Read,Update,Delete). Если в вашей системе будет много чтения, вы можете подумать об использовании LDAP. Потому что LDAP быстр в операциях чтения и разработан так. Если другие операции будут сделаны больше, RDMS будет лучшим вариантом.

0