Выбор между сервером каталогов (иначе база данных LDAP) и RDBMS
Возможно, Ваше приложение является отказоустойчивым, означая, что оно проверяет, чтобы видеть, регистрируется ли источник журнала событий уже и регистрирует источник, если это не?
, Если бы это имело место, Ваше приложение воссоздало бы источник (источники) каждый раз, когда это выполнило, неважно, что Вы сделали.
6 ответов
Обычно я убегал бы от LDAP как можно быстрее, однако вы просто использовали две волшебные фразы, которые делают LDAP лучшим выбором «иерархическая природа данных конфигурации» и «данные конфигурации».
LDAP был разработан для этого (и только для этого) типа данных.
Есть и другие, более прагматические причины для выбора LDAP.
Все LDAP одинаковы. Это протокол доступа, а не реализация базы данных, поэтому, независимо от того, использует ли ваш клиент LDAP с открытым исходным кодом или коммерческий, ваше программное обеспечение не нужно будет менять.
Все СУБД разные. Какую бы РСУБД вы ни выбрали, будет по крайней мере один заказчик, который стандартизировал другую несовместимую РСУБД - если ваш продукт достаточно успешен, вы в конечном итоге будете поддерживать форк как минимум для MySQL, Postgress, SQLServer, Oracle, DB2 и Sybase.
Если ваш заказчик / начальник ворчит, что он не такой надежный / производительный / транзакционный, как ORACLE / DB2, укажите, что заказчик может использовать реализацию LDAP ORACLE или DB2.
Единственным реальным недостатком является отсутствие опыта работы с LDAP там. Большинство разработчиков имеют опыт работы с LDAP только со схемой безопасности пользователя по умолчанию, которая поставляется с J2EE.
Схемы LDAP - это базы данных, и для них потребуется база данных, такая как процедуры администрирования и контроля изменений!
- Элемент списка
Если вы просто ищете базу данных для изменения конфигурации, вам подойдет РСУБД. Это распространенная ИТ-проблема, и существуют различные коммерческие решения. Возможно, стоит взглянуть, что там есть, прежде чем вкладывать большие средства в собственное решение.
Если вы хотите в конечном итоге включить интегрированную аутентификацию на нескольких платформах (windows / linux / и т. Д.), То LDAP - это то, что вам нужно. идти. Мало того, что большинство серверных и настольных ОС поддерживают аутентификацию LDAP изначально, LDAP можно легко кластеризовать или синхронизировать на нескольких сайтах.
Вполне возможно, что вы получите гибридное решение. Большая часть вашей базы данных управления изменениями (CCDB) может находиться в РСУБД, но аутентификация может обслуживаться с помощью кластера LDAP. Единый интерфейс может управлять информацией в обоих. Избегайте хранения паролей учетных записей в вашей CCDB, по соображениям безопасности вместо этого используйте LDAP.
Независимо от того, используете ли вы RDBMS или LDAP, вы, вероятно, будете писать сценарии оболочки, приложения или веб-интерфейсы для добавления / обновления информации в ваш CCDB. Это помогает сократить время обучения для новых сотрудников, а также упрощает и контролирует обновления базы данных управления изменениями.
Не стоит недооценивать риски, связанные с указанием нового сотрудника на исходную СУБД и надеждой на лучшее. Схемы комплексных CCDB могут быть очень сложными, независимо от того, какую технологию вы выберете для их моделирования.
Это помогает сократить время обучения для новых сотрудников, а также упрощает и контролирует обновления базы данных управления изменениями.Не стоит недооценивать риски, связанные с указанием нового сотрудника на исходную СУБД и надеждой на лучшее. Схемы комплексных CCDB могут быть очень сложными, независимо от того, какую технологию вы выберете для их моделирования.
Это помогает сократить время обучения для новых сотрудников, а также упрощает и контролирует обновления базы данных управления изменениями.Не стоит недооценивать риски, связанные с указанием нового сотрудника на исходную СУБД и надеждой на лучшее. Схемы комплексных CCDB могут быть очень сложными, независимо от того, какую технологию вы выберете для их моделирования.
Я бы выбрал подход РСУБД по следующим причинам:
- Вы можете легко изменять и расширять ее структуру.
- Если ваша сеть, которую вы моделируете, похожа на мою, было бы катастрофой пытаться моделировать это в иерархической манере. (Это не по сути.). например, правила брандмауэра, доступ сервера к другим серверам, подсети и т. д.
- Об этом чрезвычайно легко сообщить.
- Легче найти разработчиков, обладающих навыками SQL, чем LDAP.
- Относительно легко обслуживать особые случаи, может Это легко сделать в LDAP?
Сказав это, я больше знаком с подходом РСУБД, поэтому я предвзято.
Ответ прост: если вам нужен каталог, используйте LDAP. Если вам нужна база данных, используйте СУБД. Поскольку ваша цель - иметь структуру, подобную каталогу (это очень похоже на «телефонную книгу»), используйте LDAP. РСУБД - это слишком много накладных расходов для того, что вам нужно.
Я не уверен, что здесь применим аргумент «никого не уволили за ...». В конце концов, вам действительно нужен сервер каталогов, мы не говорим о запросе, который стоит в середине мыслимой оси базы данных LDAP.
Я определенно выбрал бы LDAP, хотя я не могу поставить себя на место оператора человек, которого могут уволить за выбор решения сервера каталогов, соответствующего проблеме сервера каталогов ...
Я бы склонился к LDAP из-за структуры ваших данных, и хотя я считаю, что должно быть больше людей, которые имеют дело с иерархическими базами данных и уйти от менталитета «СУБД - единственная база данных», я не знаю легко переносимого сервера LDAP, который можно было бы встроить в более крупное приложение.
Вы можете использовать SQLite, если хотите пойти по маршруту DRBMS, но на самом деле я бы выбрал третий вариант - базы данных XML. Поскольку вы уже используете XML, мы надеемся, что вам будет легко перейти на что-то вроде Berkeley DB XML для хранения. Вы также можете проверить в Википедии список других альтернатив
(и заявление об отказе от ответственности - я никогда не использовал базы данных XML; я использовал OpenLDAP, iDS,