¿Por qué ‘No se pueden hacer combinaciones’ se considera un argumento fuerte contra las bases de datos NoSQL?

Las uniones permiten un grado masivo de flexibilidad en el modelo de datos. En una base de datos que permite uniones calculadas (es decir, bases de datos relacionales), no tiene que conocer las búsquedas exactas que se realizarán de antemano cuando diseñe el modelo de datos. En las bases de datos que no permiten combinaciones, debe diseñar cuidadosamente el modelo de datos para admitir tipos particulares de búsquedas, y si elige mal, no tiene suerte. En el mejor de los casos, debe construir nuevas estructuras de búsqueda utilizando operaciones por lotes estilo Hadoop.

Esto puede no importar si tiene una aplicación “solo de búsqueda” en la que todo lo que tiene es un identificador y un montón de cosas, pero si permite búsquedas en propiedades generales, esto se convierte en una preocupación importante.

Dicho esto, a medida que los conjuntos de datos alcanzan tamaños de “escala web” (es decir, tamaños de datos de TB múltiple, tablas de miles de millones de filas), incluso las bases de datos relacionales deben diseñarse en torno a patrones de búsqueda específicos, y el fragmentación se convierte en una preocupación, por lo que En esos tipos de bases de datos, la principal ventaja que ofrecen las combinaciones es la flexibilidad en los tipos de búsquedas, pero las consultas aún tienen que encajar en el “patrón” de búsqueda para el que se diseñó originalmente el modelo de datos.

Si desea tener algún tipo de normalización en una base de datos NoSQL, su aplicación debe administrar realizar múltiples consultas y reunir los datos resultantes. A veces es preferible usar SQL y dejar que la capa de la base de datos maneje esto a través de una unión.

Si tiene una base de datos completamente desnormalizada, entonces diría que no tiene un argumento sólido contra las bases de datos NoSQL. De lo contrario, cuanto más normalizado requiera que sean sus datos, más fuerte será su argumento en contra de NoSQL.

En última instancia, la estructura de sus datos es lo que debe determinar qué sistema de base de datos elige. Para los datos transaccionales o los datos donde necesita un alto grado de integridad, sería mejor optar por una base de datos relacional. Si el rendimiento es importante para usted y no le importa un poco de desnormalización, elija una base de datos NoSQL.

Para los DBA de SQL tradicionales, no puede hacer uniones, lo que significa que NoSQL carece de una funcionalidad importante.

Estos últimos años nos han alejado más de las uniones y hay varios patrones a seguir para evitar que traslademos las uniones de la base de datos a nuestro código.

Primero, es importante que establezcamos nuestras “fuentes” de verdad. El Modelo es la primera fuente de verdad. Esto ofenderá la sensibilidad de muchas personas y el principio DRY.

Luego debemos desnormalizar, desnormalizar y distribuir dentro de nuestro modelo. Piense en todos los casos de uso posibles en los que usaría una unión y distribuiría los datos apropiados.

Luego, utilice contextos limitados y practique el diseño impulsado por dominios. bliki: BoundedContext

Escriba sus actores y eventos para actualizar sus datos. http://flow-design.org/overview/ …

En general, “No se pueden hacer combinaciones” ya no se considera un argumento válido contra la base de datos NoSQL, se considera un signo de ignorancia. Generalmente feliz, así que sé gentil.

Es la definición de NoSQL, una categoría múltiple de tipos diferentes, definida solo por la falta de características relacionales, que básicamente significa uniones.

Las otras respuestas explican casos en los que las uniones son útiles. También pueden llevar mucho tiempo.

Por el contrario, incluso si no necesita uniones, eso no requiere un software incapaz de unir. Simplemente puede usar MySQL como un almacén de tablas basado en su confiabilidad y velocidad, y nunca hacer uniones.

En una situación en la que no necesita hacer decenas de miles de solicitudes por segundo, las uniones pueden ser útiles. Nada es más expresivo que un operador SQL de tres líneas con toneladas de combinaciones. En serio, escribir lo mismo que funciona y se depura en un lenguaje de programación como C ++ llevaría décadas. Todo tiene su lugar y su tiempo.

Es costoso (tiempo del desarrollador) y propenso a errores si tiene que codificar toda la lógica de unión usted mismo que un sistema SQL haría por usted.