Una base de datos de usuario para varias bases de datos de aplicaciones

Question

Estoy administrando una base de datos bastante grande que ha crecido en complejidad y diseño desde una sola base de datos de aplicaciones. Ahora hay un plan para agregar una quinta aplicación que lleva consigo su propio esquema y datos específicos. He estado investigando soluciones SSO, pero eso no es realmente lo que busco. Mi objetivo es tener un punto de registro de clientes, inicios de sesión y autorización.

Idealmente, cada aplicación solicitaría autenticación y se le otorgaría autorización para múltiples aplicaciones, donde las aplicaciones se conectarían luego a la base de datos apropiada para las operaciones. No tengo experiencia de primera mano para lidiar con este grado de separación, ya que la base de datos ha estado funcionando sin problemas durante años. Cualquier mejores documentos de la práctica sería apreciado :)

Me gustaría imaginar una base de datos central que mantenían datos compartidos - Cliente/Empresa/Productos

1. mesas centrales y claves primarias -Para mantener la integridad referencial que deben tener una tabla replicada más pequeña en cada base de datos de "aplicación". ¿Cuáles son algunas formas de compartir claves entre varias bases de datos y garantizar la integridad referencial?

2. Replicación - Dos suscriptores actualmente extraen datos de la base de datos de producción donde los datos se combinan posteriormente en una solución DW para generar informes. ¿Estoy yendo por un camino que puede llevar a la frustración?

3. integridad de los datos - ¿Cómo se puede garantizar que, por ejemplo, que: DATABASE_X.PREFERENCES.USER_ID = siempre hace referencia a = CORE_DATABASE.USERS.USER_ID

4. informes - ¿Qué tipo de obstáculos iba a cruzar para replicar/transformar datos de múltiples bases de datos en una base de datos de informes?

5. White Papers - ¿Alguien puede encontrar buenas referencias a esta estrategia en la práctica?

Gracias

Answer 1

Algunas direcciones URL para usted. Las implementaciones de escalado pueden variar ampliamente para satisfacer los requisitos, pero esperamos que puedan ser de ayuda.

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

éste es 2.005 centrada, pero es muy buena http://msdn.microsoft.com/en-us/library/aa479364.aspx#scaloutsql_topic4

ésta una buena solución para la presentación de informes ... http://msdn.microsoft.com/en-us/library/ms345584.aspx

que dieron un servicios de análisis de uno también :) http://sqlcat.com/whitepapers/archive/2010/06/08/scale-out-querying-for-analysis-services-with-read-only-databases.aspx

Answer 2

he creado algo como esto hace unos años con vistas y procedimientos almacenados para traer los datos de la base de datos principal en las bases de datos subordinados. Esto le permitiría unir fácilmente esas tablas maestras en las otras tablas subordinadas.

Answer 3

¿Ha estudiado el uso de RAC? Puede tener varias bases de datos físicas, pero solo una base de datos lógica. Esto resolvería todos sus problemas de integridad. Y puede apartar nodos solo para informar.

Answer 4

No tire a cabo la idea de tener aplicaciones separadas y la vinculación de las funciones de inicio de sesión/apagado a través del webservice peticiones (esque). He visto los sistemas de facturación/registro de usuarios separados de esta manera. Aunque a escalas extremadamente grandes, esta podría no ser una buena idea.