¿Es una buena idea usar Sinónimos para evitar crear una tabla duplicada?

Tenemos 3 copias de la misma base de datos. Las 3 bases de datos tienen una Userstabla, y siempre existirá un Usuario en las 3 bases de datos con la misma configuración. Cada vez que deseamos agregar o editar un usuario, tenemos que actualizar 3 bases de datos.

¿Sería una mejor idea eliminar la Userstabla de las bases de datos 2 y 3 y reemplazarla por una Synonymque apunte a la base de datos 1?

Aquí están los pros / contras en los que puedo pensar:

Pros

• Mantenimiento más fácil. Puede actualizar usuarios en una ubicación en lugar de 3
• Los Id. De usuario coincidirían entre las bases de datos (importante ya que muchas aplicaciones complementarias se basan en Id. De usuario)

Contras

• No piense que este es un procedimiento estándar, por lo que podría ser confuso.
• Los usuarios tendrían que tener configuraciones idénticas entre las bases de datos
• (De la respuesta de gbn a continuación) Si la base de datos 1 alguna vez deja de funcionar , las bases de datos 2 y 3 tampoco estarán disponibles. También existe el problema potencial de que los datos sean inconsistentes en el caso de una restauración

Esta es una opción que estoy considerando para algunas tablas diferentes que contienen configuraciones que son idénticas entre las bases de datos, no solo la Userstabla. Estoy usando Usuarios en el ejemplo, ya que es fácil de entender.

¿Por qué tienes 3 bases de datos con los mismos usuarios?

¿Qué sucede si una base de datos se cae ahora?

Estoy haciendo estas preguntas porque la estafa de la base de datos de origen del usuario que se está cayendo, lo que impide el uso de las otras dos bases de datos, puede no ser un problema tan grande como parece.

Además, si una base de datos se cae ahora, ya tendrá problemas de coherencia si los usuarios se modifican en las otras dos bases de datos durante ese período. No creo que podamos dar el mejor consejo sin más contexto.

En este momento, crearía una cuarta base de datos para usuarios, realizaría cambios solo allí y sincronizaría las otras bases de datos. Ya está distribuido-desnormalizado cambiando esencialmente los mismos datos en tres lugares, y probablemente ya tenga problemas de consistencia. Si la tolerancia a fallas es importante, entonces este esquema aún da eso mientras resuelve el problema de entrada múltiple.

Creo que tener esta cuarta base de datos solo de usuario / configuración en lugar de usar una de las existentes es una buena estrategia, ya que es menos probable que disminuya, ya que no está vinculada a otros recursos o es muy utilizada. Ahora veo que dijiste que no puedes hacer esto, pero no tengo claro por qué. ¿Las aplicaciones en la base de datos principal admiten la edición del usuario directamente, o la edición del usuario es una función completamente separada que puede apuntar a otra parte?

Es cierto que con esta idea de "tabla de usuario canónica", ya sea que use sinónimos o sincronice los datos, no puede modificar usuarios durante una DB de usuario inactiva, pero eso me parece correcto. ¡Solucione el problema y tráigalo! Una fuente, un lugar para editar, una cosa para arreglar si está roto. Con la sincronización, todas las demás bases de datos tienen copias temporales desde las que pueden trabajar, pero no pueden editarse. Minimizar la duplicación de datos en los sistemas es un objetivo excelente y útil. Ingresar los mismos datos en tres lugares es un problema grave, así que haga todo lo posible para eliminarlos.

Para abordar más de sus comentarios, si sus ID de usuario son diferentes en todas sus aplicaciones, entonces debería considerar seriamente un tiempo de inactividad planificado para que sus dos nuevas bases de datos estén sincronizadas con la principal (haga una pregunta por separado si necesita ideas sobre cómo lograr esto, lo cual es complicado pero no es TAN difícil)

Si analiza las necesidades de su negocio y descubre que la base de datos principal debe tener los datos de usuario que están bien, todavía la usa como canónica, luego elija entre sinónimos o sincronización para abordar cómo los tiempos de inactividad no planificados afectan a todas las bases de datos.

Una desventaja adicional del uso de sinónimos es que ya no podrá tener FK adecuados para los usuarios en cada base de datos.

Falta una "estafa"

En la restauración, es posible que su usuario no exista en la base de datos de destino (del sinónimo). Digamos que está dañado, y debe restaurar desde una copia de seguridad.

Es decir, el uso de sinónimos asumirá una integridad referencial entre bases de datos que no puede suceder en la vida real.

Otra consecuencia de esto sería un ID de usuario no coincidente cuando intente recuperarse de esto. (agregando el usuario después de la restauración). Sin embargo, esto nunca debe suponerse de todos modos debido a la integridad referencial entre bases de datos que mencioné.

Entonces, no lo hagas ...

Una respuesta relacionada en dba.se: Criterios de decisión sobre cuándo utilizar un esquema no dbo frente a una nueva Base de datos sobre "integridad referencial entre bases de datos" después de las restauraciones

Dependiendo de su plataforma de base de datos, otra opción es eliminar las tablas en las bases de datos 2 y 3 y reemplazarlas con vistas materializadas de la tabla en la base de datos 1.

Pros

• Mantenimiento más fácil (de los datos)
• Ids a juego
• Las interrupciones no afectan a otras bases de datos (al menos hasta que sea necesario realizar cambios)
• Se puede usar cualquier base de datos para recuperar la tabla.

Contras

• Los datos solo están tan actualizados como su programa de actualización.
• Si la definición de la tabla cambia, las vistas materializadas también podrían necesitar cambios.

También tenga en cuenta que, dependiendo de la frecuencia de las búsquedas, la frecuencia de las actualizaciones y la frecuencia del cambio de datos, esto puede o no introducir más carga que una solución sinónimo.

Actualización: El comentario de FrustratedWithFormsDesigner es esencialmente una Vista materializada para plataformas que no pueden hacer vistas materializadas. Usando un script, las tablas podrían sincronizarse periódicamente. Si una base de datos se designa como maestra, entonces todos los scripts podrían realizar sus cambios en función de ella. Esto tendría todos los pros y los contras de una vista materializada; simplemente no podía aprovechar la funcionalidad incorporada.

Crearía una cuarta base de datos que almacena la información de usuario compartida. Cree Synonymso Viewsen cada uno de los otros Dbs apuntando a la base de datos de usuarios.

Por último, crearía una tabla de extensión (una tabla con una relación One-one con el 'UserDB.Usertable') en cada uno de los 3 dbs existentes que contiene datos de usuario específicos de esa aplicación.

Editar: según el comentario a continuación

En ese caso, haga que First db actúe como la tabla maestra de usuario. Synonymsy una tabla de extensión en cada uno de los Otros Dbs.

Nota importante : con este enfoque, si su primera aplicación se cae, las otras dos se despliegan con ella. Asegúrese de que todos entiendan este inconveniente.