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

13

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.

sql-server database-design Rachel
fuente
3
¿Tendría más sentido tener un script para sincronizar / fusionar las diferencias entre ellos? Personalmente no me gusta hacer que 2 bases de datos dependan de un tercero debido a un sinónimo como este.
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner Eso parece mucho más trabajo, y es difícil combinar cambios en los campos generados automáticamente, como una clave principal.
Rachel
Depende de lo elegante que quieras ser. Si desea compartir cambios entre ellos, entonces sí, puede complicarse. Si desea designar a uno como Maestro, simplemente se trata de sobrescribir los contenidos de los demás con los contenidos del Maestro.
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner Desafortunadamente, la aplicación es de código cerrado y no hay nada que impida que las personas agreguen o editen usuarios en cualquier Base de Datos. Tendría que hacer los cambios en ambos sentidos, ya que todos tienen la capacidad de cambiar su propia contraseña, y casi todos los gerentes tienen acceso a la administración de usuarios para agregar / editar usuarios.
Rachel

Respuestas:

6

¿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.

ErikE
fuente
3

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

gbn
fuente
Buen punto sobre la posibilidad de que el objetivo no exista, aunque todavía estoy tratando de descubrir por qué el enlace está relacionado con esta pregunta
Rachel
1
@Rachel: no, la tabla de destino puede existir pero los datos pueden ser más antiguos. Entonces, cuando restaura, tiene un usuario perdido ... El enlace trata sobre "integridad referencial entre bases de datos"
gbn
2

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.

Leigh Riffel
fuente
1
No puede materializar vistas (vistas indexadas aquí) cross-db en SQL Server + no necesitan actualizarse: son "en tiempo real"
gbn
@gbn Mi publicación se escribió antes de agregar la etiqueta de SQL Server.
Leigh Riffel
Agregué la etiqueta en función de su respuesta :)
Rachel
1

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.

Imbéciles
fuente
Lamentablemente, esa no es una opción para mí. Sería mi opción preferida si estuviera diseñando algo desde cero, pero en este caso estoy trabajando con un sistema preexistente. En mi caso, teníamos la Base de datos 1 que existió durante muchos años, y recientemente agregamos las Bases de datos 2 y 3.
Rachel
¿Por qué puede eliminar las tablas y señalar el Sinónimo al primer db pero no a uno nuevo?
Lo siento, edité mi comentario antes de ver el tuyo. La base de datos 1 existe desde hace muchos años y muchas aplicaciones externas acceden a ella. No estoy seguro de qué tipo de daño causaría al eliminar esa tabla. Las bases de datos 2 y 3 son más nuevas, así que creo que puedo eliminar la tabla Usuarios (y otras tablas de configuración) y reemplazarlas por sinónimos
Rachel
Veo tu edición ... eso es exactamente lo que estoy tratando de hacer, pero mi pregunta es si es una buena idea o no, y si no, ¿por qué?
Rachel
Está bien. Si está de acuerdo, hacer que las 2 aplicaciones de noticias dependan completamente de la primera aplicación.