Одна база данных пользователей, обслуживающая несколько баз данных приложений

Question

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

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

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

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

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

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

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

5. White Papers - Можно ли найти хорошие ссылки на эту стратегию на практике?

Благодаря

Answer 1

Несколько 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

Answer 2

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

Answer 3

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

Answer 4

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