Одна база данных пользователей, обслуживающая несколько баз данных приложений - PullRequest
5 голосов
/ 10 февраля 2011

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

В идеале, каждое приложение должно запрашивать аутентификацию и получать авторизацию для нескольких приложений, где приложения затем подключаются к соответствующей базе данных для операций.У меня нет личного опыта, связанного с такой степенью разделения, поскольку единственная база данных годами безупречно работала.Буду признателен за любые передовые практические документы:)

Я представляю основную базу данных, в которой хранятся общие данные - Заказчик / Компания / Продукты

  1. Основные таблицы и первичныеКлючи - для сохранения ссылочной целостности, если в каждой базе данных «приложения» имеется реплицируемая таблица меньшего размера.Каковы некоторые способы совместного использования ключей между различными базами данных и обеспечения ссылочной целостности?

  2. Репликация - Два подписчика в настоящее время извлекают данные из производственной базы данных, где данные впоследствии группируются вDW решение для отчетности.Я иду по дороге, которая может привести к разочарованию?

  3. Целостность данных - Как я могу убедиться, например, что: DATABASE_X.PREFERENCES.USER_ID = всегда ссылается на = CORE_DATABASE.USERS.USER_ID

  4. Отчетность - Какой тип препятствий я бы пересек для репликации / преобразования данных из нескольких баз данных в одну базу данных отчетов?

  5. БелыйДокументы - Кто-нибудь может найти хорошие ссылки на эту стратегию на практике?

Спасибо

Ответы [ 4 ]

1 голос
/ 14 февраля 2011

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

http://blogs.msdn.com/b/sqlcat/archive/2008/06/12/sql-server-scale-out.aspx

этот ориентирован на 2005 год, но ОЧЕНЬ хорош http://msdn.microsoft.com/en-us/library/aa479364.aspx#scaloutsql_topic4

этотодно хорошее решение для составления отчетов ... http://msdn.microsoft.com/en-us/library/ms345584.aspx

, предоставленное вам также для аналитических служб :) http://sqlcat.com/whitepapers/archive/2010/06/08/scale-out-querying-for-analysis-services-with-read-only-databases.aspx

0 голосов
/ 14 февраля 2011

Не отказывайтесь от идеи иметь отдельные приложения и связывать функции входа / выхода через запросы веб-службы (esque). Я видел системы биллинга / регистрации пользователей, разделенные таким образом. Хотя в очень больших масштабах это может быть не очень хорошая идея.

0 голосов
/ 11 февраля 2011

Вы изучали использование RAC?Вы можете иметь несколько физических баз данных, но только одну логическую базу данных.Это решит все ваши проблемы с честностью.И вы можете выделить узлы только для отчетов.

0 голосов
/ 10 февраля 2011

Я создал нечто подобное несколько лет назад, используя представления и хранимые процедуры для ввода данных из основной базы данных в подчиненные базы данных.Это позволит вам довольно легко объединить эти основные таблицы в другие подчиненные таблицы.

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