Normalización de base de datos vs dependencias

Estoy desarrollando 3-4 programas interdependientes. Llámalos foo bar baz y auth. Quiero que sean independientes el uno del otro. Imagínese si licenciara cada programa a otras compañías. Algunas compañías pueden querer foo y bar, otras pueden solo querer baz, etc. También parece una buena práctica mantener la autenticación independiente también.

Contexto: auth se encarga de la autenticación para todos los sistemas. La tabla principal de usuarios en auth tiene user_id, correo electrónico, contraseña, primero, último

foo también tiene una tabla de usuarios que tiene campos específicos para la aplicación: user_id, role_id, etc.

Cada sistema tiene su propia base de datos. En el pasado, he creado una clave foránea de cada aplicación para la autenticación db. Eliminé los permisos de actualización de los otros dbs pero otorgué acceso selecto a ciertos campos relevantes. Esto parece una mala solución porque crea una dependencia estrecha, pero me permitió normalizar el db para que no tuviera que almacenar el nombre y el correo electrónico de los usuarios en las bases de datos foo, bar o baz.

¿Sería mejor almacenar la información en todas las bases de datos? ¿O sería mejor almacenar el Id. De autenticación en foo bar y baz y usar una API para obtener la información del usuario usando el authId?

Del mismo modo, podría tener clientes en los 3 sistemas. Claro que parece malo crear una dependencia en una base de datos de autenticación, pero ¿qué pasa con la base de datos del cliente en los 3?

O es la mejor solución para tener una base de datos central. Una tabla de usuarios.

¿Otras sugerencias?

Si tiene 4 servicios independientes, entonces tienen que ser independientes. No se deben compartir datos en bases de datos comunes o similares, ya que simplemente los hace dependientes.

Ahora, aunque está bien compartir una única base de datos en producción, los servicios deberían usar sus propios esquemas en cuanto a que la base de datos está ahí como un contenedor común, similar a cómo un solo servidor Linux puede ejecutar los 4 servicios.

Cada servicio debe tener su propia API, y esta es la única forma de obtener datos dentro y fuera de cada uno. Por lo tanto, su servicio de autenticación almacenará usuarios y realizará la autenticación, pero devolverá algún token para identificar a un usuario. Este token es lo que usan los otros servicios para recordar qué usuario es cuál, pero de lo contrario no deberían tener ningún conocimiento de la autenticación del usuario.

La forma más fácil de pensar en implementar esto es pensar qué haría si decidiera utilizar un servicio de terceros en lugar de los que está escribiendo, si utilizó el servicio OpenID de StackExchange para usuarios en lugar del suyo. Si puede reemplazar eso en su arquitectura, entonces tiene un buen diseño independiente.

Su ejemplo es un poco abstracto, pero déjenme analizar mis pensamientos.

Opción A: En mi experiencia, esto siempre es malo, independientemente de sus razones. Seguro que las bases de datos como MSSQL pueden tener bases de datos amigas, etc., pero si los datos están vinculados, deben estar en la misma base de datos

Opción B: ¿No está seguro de lo que está sucediendo aquí, está agregando una API que consulta todos los DB y reúne los resultados? Esto es mejor, pero si tiene aplicaciones encima de esa API, entonces es parte de la capa de datos para ellas y realmente solo usan una de las bases de datos, entonces, ¿por qué tienen las otras en su capa de datos?

Opción C: Bueno, esto funciona, pero no es bueno tener una gran base de datos con datos no relacionados. ¿Quieres que los programas sean independientes entre sí, verdad? esta dosis ayuda con eso.

Opcion D

Mi sugerencia es abstraer la autenticación del concepto de ID de usuario. su aplicación de autenticación debe preocuparse por los usuarios y roles (o promesas, etc., si se está volviendo moderno), estos datos deben existir en la base de datos de autenticación

Cada aplicación debe tener un ID de usuario para agrupar datos por usuario, con algunos datos relacionados para realizar la llamada de autenticación e identificar al usuario ante los humanos. esto sería userId (exclusivo de la aplicación), nombre real, authusername, servicio de autenticación para usar. Estos datos deberían existir en la base de datos de aplicaciones

Las bases de datos no deberían tener conexión entre ellas, conceptualmente debería poder usar Facebook como su servicio de autenticación en lugar de su aplicación de autenticación

Es posible que necesite una información de enlace de Usuario adicional si desea relacionar un usuario foo con un usuario de barra

Recomendaría implementar Single Sign On (SSO), por ejemplo con LDAP. Sus clientes más grandes probablemente también se habrían beneficiado de ello, ya que podrían reemplazar su aplicación de autenticación incorporada con su propia base de datos de usuarios existente. Para sus clientes más pequeños que no admiten SSO, puede simplificar la implementación enviando su aplicación con una aplicación de autenticación predeterminada.