El uso de una base de datos significa principalmente establecer una conexión y enviar solicitudes (SQL). El lado frontal normalmente no utiliza ninguna base de datos directamente, sino a través de scripts o puntos finales de Rest API y la conexión directa de la base de datos se realiza solo en el lado del servidor.
Nada habla en contra de tener conexiones a diferentes bases de datos, siempre que los módulos de su aplicación tengan todos los controladores ODBC necesarios o mientras la API o las API hagan uso de las dos bases de datos en el back-end. Un caso simple de esto son las aplicaciones que publican en Facebook y Twitter, simplemente usan ambas API del sistema y, por lo tanto, usan dos bases de datos diferentes, incluso dos servidores diferentes.
Para las aplicaciones web que utilizan la base de datos Web SQL, es la norma tener el almacenamiento local (generalmente SQLite) en la parte superior de la base de datos de back-end. Normalmente, el lado del cliente JS utiliza el motor local SQLite. Sin embargo, no puede significar eso, ya que solo se trata de almacenar localmente datos adicionales.
- ¿Cuáles son las mejores y mejores empresas de desarrollo de aplicaciones móviles?
- Desarrollo de aplicaciones vs redes?
- ¿Cuáles son las principales empresas de desarrollo de aplicaciones para iPad?
- ¿Quiénes son los mejores desarrolladores de aplicaciones móviles en Florida?
- ¿Por qué las tiendas de aplicaciones móviles no envían el código fuente o el código de byte y compilan al nativo directamente en el dispositivo móvil?
Para un módulo de fondo simplemente necesita dos conexiones diferentes, incluso podría usar la misma tecnología / idiomas para eso, siempre que el servidor tenga controladores para ambos.
Esto puede permitir reunir dos módulos utilizando una y otra base de datos sin migrar primero uno de los módulos. Tan pronto como los datos de la otra base de datos también sean importantes, almacenará los datos dos veces (usuarios para el chat y usuarios para el inicio de sesión principal y el perfil y cualquier información relacionada) y se arriesgará a que se separen o establezca la segunda conexión dentro del mismo módulo, pero necesitará unir datos después de consultar las dos bases de datos por separado.
MSSQL ofrece servidores vinculados, que ni siquiera necesitan ser servidores MSSQL. Eso permitiría unirse desde diferentes bases de datos, haciendo que su conexión única al servidor MSSQL que tiene el servidor o servidores vinculados, pero eso no hace que sea mucho más rápido que consultar cada uno, la tarea de unir datos no es tan optimizable como es con datos en una sola instancia e incluso en una sola base de datos en esa única instancia.
Esa puede ser la razón principal por la que no se hace. Tarde o temprano, necesitará unir los datos de ambas bases de datos y luego estar vinculado a una solución subóptima. Incluso los servidores vinculados generalmente solo se usan para uso paralelo durante las fases de migración como solución “temporal” (incluso si eso puede extenderse durante varios años). Por lo general, el servidor vinculado es una base de datos heredada y se sincroniza con una nueva base de datos MSSQL nativa.
Al final depende. Cuando vea el módulo de chat como un complemento sin importancia, no involucrado con muchos datos aparte de los usuarios, puede valer la pena mantener el tráfico hacia los datos principales y los datos de chat por separado, pero dentro de una única base de datos también hay formas de separar la carga , si eso es una preocupación.
