Veo sitios que usan múltiples bases de datos, como NoSQL y SQL juntos, ¿cómo se hace esto?

Las bases de datos NOSQL y SQL almacenan datos en una estructura lógica llamada tabla (físicamente los datos se almacenan de manera diferente, pero la aplicación se presenta en filas y columnas). Las tablas se parecen a una hoja de cálculo con columnas (de ciertos tipos de datos) y una fila para cada elemento. Piense en los estudiantes en una base de datos de clase. El nombre, apellido, número de estudiante y números de clase son columnas. Tendrías una fila para tu información, yo tendría una fila para mi información, etc.

Las tablas en SQL dbs están diseñadas para contener la información requerida por una aplicación (las columnas) y le permiten relacionar información en una tabla con información en otra tabla (por ejemplo, qué estudiantes están en qué clases).

Una aplicación se conecta a una base de datos y ejecuta comandos (las sentencias SQL para bases de datos SQL, las bases de datos NOSQL pueden usar un lenguaje diferente, pero aún almacenan sus datos en Tablas).

No hay nada que detenga una aplicación para conectarse a más de una base de datos a la vez. Por ejemplo, puede tirar de uno y colocarlo en otro. A menudo, el desarrollador de la aplicación realmente desea una mayor integración entre las bases de datos (por lo que no tiene que desarrollarla + mantenerla). Preferirían si pueden usar SQL contra una base de datos que no sea SQL y puedan unir información entre las bases de datos.

Cuando lo piensas, eso no es un gran obstáculo lógico. Muchas bases de datos relacionales proporcionan acceso a bases de datos remotas, incluidas las bases de datos NOSQL. Postgres tiene Envoltorios de Datos Extranjeros, Microsoft tiene Servidores Vinculados, Oracle e IBM tienen sus propios nombres para utilidades similares, aunque solo sea para competir con otras bases de datos relacionales.

En el otro sentido (acceso NOSQL a una base de datos relacional), no hay tanto soporte (que yo sepa, aunque puede estar en el horizonte).

Por lo general, el acceso SQL de las bases de datos NOSql es para extraer datos de un almacén nosql para integrarlos en un escenario de informes (las bases de datos NOSQL carecen de muchas características de lenguaje que requieren casos de uso de informes, como uniones a otras tablas, agrupación, clasificación, etc.). Por lo general, no actualiza nosql desde sql a través de dicho enlace.

Es fácil de lograr si ese CMS está escrito por este paradigma en mente. De hecho, experimenté un poco al respecto.

Las bases de datos NoSQL se describen a sí mismas como “almacenamientos rápidos sin SQL”, sin embargo, eso no es cierto. De hecho, curiosamente, son más rápidos en las escrituras, que es un rasgo que no usa mucho si desea usarlo como almacenamiento para frontend. MySQL me dio mejores velocidades de lectura (SELECT) en general.

Puede haber UN uso, que no está relacionado con las deficiencias de RDBMS, pero su falta de uso de mejores prácticas como la normalización. Por ejemplo, veo demasiadas uniones innecesarias o consultas múltiples. Este es un error de diseño, lo que da una pista de que nos enfrentamos a un código de ayuda de banda no planificado. ¿Puedes arreglarlo?

Normalmente, es demasiado difícil de solucionar, porque tienes que cambiar la estructura de tu base de datos. Entonces, en estas situaciones, tiene sentido emplear otro motor de base de datos como middletier. Por ejemplo, si tiene que crear una página consultando 23 tablas, varias UNIONES, demasiadas consultas, simplemente cree la página y guárdela en una base de datos nosql.

Sí, esta es una forma de almacenamiento en caché, aunque 😉

Vemos demasiados paradigmas por todas partes, la mayoría de ellos le dan nuevas malas prácticas, y algunos intentan arreglar cosas rotas con otras ideas menos pero aún rotas.

Como regla general, se usan “en tándem”, pero no “juntos” en el sentido de compartir los mismos datos.

Lo que pueden tener son varias claves lógicas que apuntan de una a otra, y a menudo ambas.

Por ejemplo, puede tener un juego multiusuario en el que represente a jugadores, armas y otros artículos de inventario, y otros “usables” como entradas en una base de datos relacional como MySQL, particularmente si son cosas que se pueden comprar con el juego moneda o dinero real (en cuyo caso también habría enlaces a un sistema de facturación y pagos).

Puedes elegir representar el mapa del juego en sí mismo con algo como MongoDB, donde puedes almacenar documentos que representan la topografía de partes particulares del mundo del juego. Las cosas que tienen presencia física en el mundo del juego pueden tener teclas que apuntan al mundo de MongoDB que indican su ubicación física en el mapa, o pueden tener trozos en MongoDB con teclas que apuntan a la base de datos relacional que describe sus diversas propiedades (es decir, 3 pisos edificio de ladrillo rojo con una tienda de blindados en el primer piso y los apartamentos de los comerciantes arriba: la parte de MongoDB puede decir “La identificación del edificio xxx está aquí”).

Cuánto desea en la base de datos relacional versus la base de datos NoSQL depende en última instancia de cuán “consultable” desee que sean sus objetos; Las bases de datos NoSQL son excelentes para buscar cuando conoce una clave, y son buenas para almacenar datos bastante desestructurados, pero son menos útiles cuando desea hacer una consulta de estilo “informe”, como “cuántas tiendas de armaduras hay en esta parte del mundo, y con qué frecuencia los jugadores interactúan con ellos, y (lo que es más importante), ¿están gastando dinero real para comprar armaduras en ellos? ”.

A medida que te mueves dentro del juego, el software extraerá el mapa del terreno de MongoDB, usará ID de varios elementos en el mapa para obtener registros fuera de la base de datos relacional y usará las propiedades de visualización para dibujar la visión definitiva del mundo.

La idea general es que tendrías que decidir cuidadosamente qué datos van a dónde en tu mundo de datos, y usarías algunas nociones de “uniones entre bases de datos” ejecutadas dentro de tu aplicación para materializar vistas y acciones en el juego.

Tenga en cuenta que la interacción entre los grupos de datos se maneja a nivel de aplicación.

En cuanto a los idiomas, la única restricción es que necesitaría un idioma que se pueda conectar a todas las bases de datos que usa, por lo que prácticamente cualquier lenguaje razonablemente utilizado funcionaría.

Cada control que realice que necesite mostrar datos “en vivo” de alguna manera estará vinculado a una base de datos.

Debe especificar qué campos deben mostrarse y qué valores usar, por ejemplo, un cuadro de selección podría mostrar el nombre del empleado pero almacenaría el valor del empleado.

La selección sería un enlace de datos a una tabla, una vista, un procedimiento almacenado o algún SQL personalizado escrito en su aplicación (se recomienda el último)

Para obtener el método que elija para trabajar, necesita tener una conexión a la base de datos. Múltiples controles pueden ir a la misma conexión. Y puede tener múltiples conexiones … pero cada control solo puede usar una única conexión.

No, la parte difícil es si desea tener un solo control que use datos de 2 bases de datos diferentes. En este caso, la forma más eficiente de hacerlo es en la base de datos. Use un enlace entre las bases de datos y cree una vista o un procedimiento almacenado con los datos combinados. Luego, conéctelo a su sitio web.

Espero que esto ayude

Las diferentes bases de datos tienen diferentes pros y contras.

Son buenos en y para diferentes cosas.

La mayoría de los idiomas pueden hablar con muchos tipos de bases de datos, por lo que generalmente es solo una cuestión de elección.

SQL para datos transaccionales pequeños, NoSQL para datos grandes no transaccionales.