¿Tener relaciones entre bases de datos separadas es una mala práctica?

Estoy trabajando con un cliente que tiene múltiples bases de datos. Hay varias masterbases de datos de nivel que tienen relaciones con ellas desde instancebases de datos de nivel (bases de datos específicas de la aplicación). Las relaciones de instancea masterson valores enteros que representan una clave principal para las tablas en master. Las vistas y los procedimientos almacenados en el instancesestán configurados para cargar datos a mastertravés de estas claves almacenadas.

Obviamente, no existe una integridad referencial real, pero ¿es una mala práctica o los datos deberían residir en tablas de solo lectura en las instancebases de datos?

El único problema es que no existe realmente una forma conveniente de hacer cumplir estas relaciones. Puede usar una gran cantidad de disparadores, o almacenar la tabla maestra en cada base de datos de instancia y simplemente exponerlos todos como metadatos al maestro, usando una vista tal vez.

El mayor inconveniente, creo, tiene que ver con mantener los datos precisos y sincronizados, en al menos tres escenarios fuera de mi alcance (todo lo cual puede ser un problema incluso si usa desencadenantes):

• transacciones entre bases de datos coordinadas incorrectamente : por ejemplo, una transacción agrega una nueva fila al maestro, transfiere la identidad a otra transacción y luego la primera transacción se revierte.
• recuperación de una sola falla de la base de datos : una base de datos se bloquea, debe restaurarla a un punto en el tiempo, que puede haber sido antes de que otras transacciones exitosas en otras bases de datos hayan terminado. Esto podría significar que si una base de datos de instancia tiene que volver a un tiempo anterior, faltan filas que el maestro espera; Si el maestro tiene que revertir, es posible que todas las bases de datos de instancias tengan valores que no existen en el maestro.
• consistencia de la copia de seguridad en general : si necesita recuperación ante desastres, tendrá dificultades para mantener todas sus copias de seguridad completas y de registro consistentemente transaccionales en un momento determinado. Las instantáneas del sistema de archivos no ayudan con esto, e incluso los grupos de disponibilidad no garantizan la coherencia transaccional entre bases de datos para las bases de datos en un solo grupo de disponibilidad. Si tiene un desastre y necesita restaurar sus bases de datos a un nuevo sistema, no hay forma de asegurarse de que sean consistentemente transaccionales.

Dicho todo esto, siempre he sido y siempre seré fanático de separar a los inquilinos en sus propias bases de datos, y reconozco que existe un riesgo asociado con la base de datos central, pero es necesario.

(Por otro lado, debe usar nombres para sus bases de datos que no sean maestro / instancia. masterEn SQL Server definitivamente tiene un significado explícito, e incluso leer mis propias palabras arriba podrían ser ambiguas. Lo mismo para instance. En una vida anterior, ejecuté un multi -tenant system y llamamos a la base de datos central Controly las bases de datos de inquilinos, bueno ,. Tenants)

Si está siguiendo una arquitectura como Microservices, es prácticamente imprescindible poder correlacionar datos a través de múltiples servicios autónomos, cada uno con su propio almacén de datos. Cada servicio comprenderá que los procesos comerciales que tradicionalmente se realizarían en una sola transacción de base de datos ahora pueden ser potencialmente más largos.