Как разделить ответственность между LDAP и RDBMS - PullRequest
Новая
       15

Как разделить ответственность между LDAP и RDBMS

6 голосов
/ 29 октября 2009

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

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

На мой взгляд, у нас есть два основных варианта реализации:

  1. Дублирование пользовательских данных как в LDAP, так и в РСУБД.
  2. Предоставьте службе отчетов доступ к LDAP всякий раз, когда ей нужны пользовательские данные.

Хотя дублирование данных (и реализация механизмов, позволяющих это сделать), как предложено в варианте 1, кажется неправильным путем, я считаю, что вариант 2 не будет работать достаточно хорошо (как вы «присоединяете» данные LDAP к Данные СУБД так же эффективны, как и чистая реализация СУБД?).

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

1 Ответ

2 голосов
/ 29 октября 2009

Почему вы считаете, что дублирование данных было бы неправильным способом? Инструменты отчетности (веб-и т. Д.) В основном построены на базе СУБД, поэтому любой микс-н-спичка создаст ненужные сложности. Отчеты, вероятно, придется менять довольно часто (исходя из опыта), поэтому вы хотите, чтобы они были максимально простыми. Данные о пользователях, которые вы храните, вряд ли изменят свой формат очень часто, поэтому, когда у вас будет работать функция импорта, вам не нужно будет снова ее трогать.

Единственное препятствие, которое я вижу, - это задержка: как вы обеспечиваете актуальность вашей копии СУБД? Возможно, вам потребуется убедиться, что ваш код обновления записывается в оба пункта назначения. Лично я также не обязательно использовал бы LDAP для личных предпочтений приложения: LDAP не может обрабатывать транзакции, так что происходит, когда данные обновляются с нескольких направлений? (Транзакционность, конечно, также проблема с разрешением записи средств обновления в оба хранилища ...) Я бы предпочел, чтобы СУБД была главной для большинства данных, и позволяла LDAP беспокоиться только об идентификации, учетных данных и правах, которые редко изменяются только для одного набора целей. Для меня способность LDAP иметь дело с иерархическими данными не так уж и хороша.

Дублирование данных не всегда плохо, особенно если сценарии использования достаточно различны.

...