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.
- Cómo registrar una idea para una aplicación móvil para minimizar la amenaza de concepto en la etapa de desarrollo
- Para una carrera, ¿debería seguir el desarrollo de iOS solamente o también debería aprender el desarrollo de Android?
- ¿Cuántas aplicaciones usa realmente un usuario móvil promedio después de descargarlas manualmente de las tiendas de aplicaciones?
- ¿Qué estrategia deberían adoptar los estudiantes con un GPA bajo para sobresalir en el desarrollo de Android?
- ¿Qué tipo de tecnología se utiliza para programar aplicaciones de banca 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.