Diseño SQL en torno a la falta de referencias de clave externa entre bases de datos

Question

Para bien o para mal, tenemos una solución que se basa en varias bases de datos que hacen referencia a una base de datos de administración común. Las bases de datos se envían como parte de módulos, y no se requieren todos los módulos para una instalación (probablemente por qué tenemos varias bases de datos en primer lugar). La base de datos de administración es obligatoria, sin embargo ... por lo que siempre estará allí.

Me gustaría traer un poco de integridad referencial y orden al caos, pero estoy bloqueado por la incapacidad del servidor SQL para hacer claves externas entre bases de datos. NO hay mucha rotación en la base de datos, pero la información será insertada/actualizada por (ejem) usuarios no técnicos.

Mis opciones como las veo son:

a) impongan clave seudo extranjera usando disparadores (bien, pero un poco de trabajo)

b) Uso disparadores para replicar de administración para otras bases de datos (una clara receta para el desastre)

c) Imponer clave externa en pseudo código/DAL (no juega bien con ORM)

d) no se preocupe de que a nivel de base de datos, utilice el buen diseño de interfaz de usuario para asegurarse nadie hace nada estúpido y restringe el acceso/mantener la respiración o n acceso directo a SQL.

Francamente, me siento inclinado a ir con "D", pero pensé que podría salir por las opiniones más inteligente que yo ...

Answer 1

Nos tienen exactamente el mismo problema y, francamente, es una mierda. Nuestra única solución que encontramos efectiva fue la opción D y el uso de la capa empresarial para tratar de mantener las cosas sincronizadas (incluidas transacciones, etc.)

Answer 2

Suponiendo que cada módulo está configurado para que esté vinculado a la base de datos de administración, puede estar capaz de simplificar algo configurando vistas para las tablas de administración dentro de cada base de datos de módulos.

Answer 3

Dependiendo de la implementación de su base de datos, a menudo podrá vincular tablas de otra base de datos (el AdminDB) y hacer que aparezcan en sus diversas bases de datos de módulos.

En Microsoft Access puede vincular tablas haciendo clic con el botón derecho y, a continuación, seleccionando una fuente de datos ODBC. En Oracle they call it a database link. Estoy dispuesto a apostar SQLServer has some form of this implementation a menos que implemente la replicación personalizada en una sola tabla.

Una vez que enlaza en sus tablas de administración externas a las bases de datos de su módulo (o viceversa), entonces debería poder definir las restricciones como si las tablas estuvieran dentro del mismo esquema.

Una segunda opción puede ser incluso más simple. ¿Qué sucede si utiliza el mismo esquema para todos los módulos y la base de datos de administración? Usted sabe que la base de datos de administración está presente, así que simplemente ejecute la secuencia de comandos de creación de tabla contra ese esquema. Siempre que no haya conflicto de nombres de tabla/vista/procedimiento almacenado, todo debería funcionar simplemente cambiando el dblogin en todos los módulos para que coincida.

Answer 4

Tenemos tal modularidad en nuestros productos, pero nuestros requisitos de base de datos se combinan durante la instalación. Por ejemplo, nuestro paquete de administración y producto A puede ser la compra inicial de un cliente donde instalan los dos módulos en la base de datos X. Si luego compran el producto B, el componente de la base de datos se superpone a la base de datos X y se agrega el DRI.

El único caso donde he visto la necesidad de bases de datos separadas desde una perspectiva de diseño es cuando trazas una línea dura entre unidades de negocio (como una corporación) en cuyo punto el problema es realmente un tipo de partición. Great Plains Dynamics hace esto cuando tienen una única base de datos administrativa y múltiples bases de datos corporativas. Sin embargo, cada módulo en GP para una corporación determinada reside en esa única base de datos.

Por supuesto, si está atascado con bases de datos separadas, estoy de acuerdo en que D es la mejor opción.

Answer 5

Supongo que depende de la criticidad de su aplicación. ¿Desea continuar, de manera posiblemente limitada, para operar si esa base de datos de administración se cae? Si dices, de ninguna manera, si el administrador no funciona, toda la aplicación se debe detener inmediatamente, de lo que todo lo que se ha dicho hasta ahora está bien.

Si dices "bueno, hay mucho trabajo que aún se puede hacer sin la base de datos de administración". entonces preguntaría, ¿por qué crees que la replicación unidireccional es tan exageradamente exótica que es una clara receta para el desastre?

Hacer una copia de una tabla no es ciencia de cohetes en absoluto. De hecho, es tan simple como duplicar la llave de su casa. Cada pico y valle en el maestro, se transmite a una rueda de corte que da forma a un espacio en blanco. Donde hay algo de magia en la replicación de múltiples maestros, si comienzas a permitir cambios en las bases de datos remotas a los datos que provienen de los datos de administración, entonces has abierto una seria consideración de diseño.

No digo que este sea EL camino a seguir, primero tiene que responder mi pregunta inicial. Después de eso, si desea continuar con las operaciones ... no descarte la viabilidad de la replicación.

Answer 6

Me pregunto si SQL Server tiene una característica como las vistas materializadas de Oracle? Este es un objeto que define con una consulta como una vista, pero los resultados de la consulta se almacenan como una tabla. Entonces hay varios mecanismos para actualizar automáticamente.

Si existe tal característica, sugiero hacer una vista materializada de la tabla central en cada base de datos satelital. Luego puede hacer referencia a eso en sus claves foráneas. El problema principal sería si se puede actualizar con la frecuencia suficiente para sus necesidades.

Answer 7

Debe implementar una arquitectura orientada a servicios. Donde se ejecutan los diferentes servicios en el sistema con su esquema de base de datos. Luego, permita que las aplicaciones se ejecuten independientemente de cualquier base de datos, pero déjelas funcionar contra los servicios.

Answer 8

Puede abordar esto de varias maneras arquitectónicas con el fin de canalizar todos los cambios a través de un servicio central para que no puedan hacer inconsistencias, pero independientemente de la cantidad de esfuerzo que esté dispuesto a realizar (y crear un cuello de botella o un único punto de falla puede violar algunos otros requisitos que usted tiene) no podrá confiar en el motor de la base de datos para aplicarlo con una garantía como puede con una restricción FK.

A menudo tuve que lidiar con esto en situaciones de bases de datos interdepartamentales donde las cosas podrían perder sincronía porque los sistemas dispares aún no estaban completamente integrados, o las preocupaciones de seguridad requerían que tuvieran administradores separados.

En estos casos, generalmente confío en informes de excepción generados por hora, que verifican el estado de las cosas y solo informan si hay un problema. Los trabajos del Agente de SQL Server tienen poderosas capacidades de programación.Siempre utilicé tablas de registro y SQLAnswersMail para generar pequeños y agradables correos electrónicos HTML (donde los enlaces URL en los correos electrónicos podrían incluso llevarlo a las páginas de administración para corregir los problemas) a los diversos administradores del sistema, pero hay muchísimas maneras de despellejar a este gato.

Answer 9

Creo que lo curioso ... es que podría hacer una pequeña copia de MS Access de su base de datos, aplicar RI en Access ... y luego convertirla, y Microsoft Access le da la opción de elegir entre utilizar Triggers o DRI .. y estoy bastante seguro de que Microsoft Access escribirá las partes centrales de los factores desencadenantes para usted.

Mientras estamos en el tema, odio MS Access ... pero lo único que es superior con Access, es que puede aplicar RI contra una consulta (sql select, aka view) .. Realmente me gustaría que MS SQL Server tenía la misma funcionalidad.