sql server - studio - Diseño SQL en torno a la falta de referencias de clave externa entre bases de datos
exportar datos de sql server a excel (9)
Para bien o para mal, tenemos una solución que se basa en múltiples 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 algo 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 elecciones como las veo son:
a) Imponer la clave pseudoexterna usando disparadores (vale, pero un poco de trabajo)
b) Use disparadores para replicar desde el administrador a otras bases de datos (una receta clara para el desastre)
c) Imponer clave externa de psuedo en código / DAL (no funciona bien con ORM)
d) No te preocupes por el nivel de DB, utiliza un buen diseño de IU para asegurarte de que nadie hace nada estúpido y restringe el acceso / espera en el acceso directo de SQL.
Francamente, me inclino a ir con "D", pero pensé que saldría por opiniones más inteligentes que yo ...
Debería 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.
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, sugeriría hacer una vista materializada de las tablas centrales 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.
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 cuánto esfuerzo esté dispuesto a poner en eso (y creando un cuello de botella o un solo el 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.
Según 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 luego eligiendo una fuente de datos ODBC. En Oracle lo llaman un enlace de base de datos . Estoy dispuesto a apostar que SQLServer tiene alguna forma de esta implementación, salvo la implementación de 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 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.
Supongo que depende de la criticidad de tu 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: "Caramba, hay mucho trabajo que todavía se puede hacer sin el administrador de bases de datos". 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 total. 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 debes responder mi pregunta inicial. Después de eso, si desea continuar con las operaciones ... no descarte la viabilidad de la replicación.
Suponiendo que cada módulo está configurado de manera que esté vinculado a la base de datos de administración, es posible que pueda simplificarlo configurando vistas para las tablas de administración dentro de cada base de datos de módulos.
Tenemos exactamente el mismo problema y francamente, apesta. 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 en las transacciones, etc.)
Tenemos tal modularidad en nuestros productos, pero nuestros requisitos de base de datos se fusionan 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 en el que 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 negocios (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.
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 usar Triggers o DRI ... y yo Estoy bastante seguro de que Microsoft Access escribirá las partes principales de los factores desencadenantes para usted.
Si bien 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 tuviera esa misma funcionalidad.