Almacenamiento de objetos de datos: ¿puede la mesa JOIN hacer qué tabla única SELECT no puede?

Question

Ahora que los sistemas de almacenamiento "NOSQL" o "solo objetos" como MongoDB o memcached realmente están tomando impulso en el mundo. Me preguntaba si hay alguna solicitud que no se puede realizar en ellos que se puede realizar utilizando varias combinaciones de objetos (en SQL que es JOIN "table"). En otras palabras, ¿hay consultas multi-tabla que no pueden ser manejadas por varias consultas de tabla única en una fila?

Básicamente, ¿hay un caso de uso en el que una combinación de múltiples tablas no se puede replicar accediendo a una tabla a la vez en sistemas de almacenamiento basados ​​en objetos?

Aquí hay algunos ejemplos de consultas normales de 3NF que usan has_man y has_many_through relationships. Estas no son las consultas más complejas, pero deberían darle un punto de partida para el concepto. Tenga en cuenta que cualquier valor en {} significa un valor del resultado de la última consulta.

---

empresa tiene muchos usuarios

SELECT user.*, company.name as company_name FROM user 
LEFT JOIN company ON company.id = user.company_id 
WHERE user.id = 4 

vs

SELECT * FROM user WHERE id = 4 
SELECT * FROM company WHERE id = {user.comany_id} 

---

club tiene muchos estudiantes a través de Usuarios de

SELECT student.* FROM student LEFT JOIN membership on 
membership.student_id = sudent.id WHERE membership.club_id = 5 

vs

SELECT * FROM membership WHERE club.id = 5 
SELECT * FROM student WHERE id = {membership.student_id} 

La razón por la que me pregunto es porque quiero saber si los sistemas basados ​​en objetos (que se basan en el acceso a los objetos de una sola mesa a la vez) pueden hacer lo RDBMS bases de datos como PostgreSQL o MySQL puede hacer.

Hasta ahora, lo único malo parece ser que son necesarias más consultas.

Answer 1

1 - running múltiples consultas separó te deja con desorden consurrency - en el momento en que tienes algo de la tabla 1 que podría haber sido borrada y aún podría estar en la tabla 2 - ahora asuma 5 tablas correlacionadas.

2 - ejecutar consultas con, al menos, la lógica de complejidad moderada sobre los campos que no son mítica ID

3 - controlando la cantidad de datos obtenidos (que casi nunca necesita más de un 50% de los datos que se necesita para deserializar/crear objetos válidos y aún peores árboles enteros de objetos conectados)

4 - consultas correlacionadas (selecciones anidadas) que servidor SQL optimizará como uniones a la complejidad aditiva o mejor (| T1 | + | T2 | + | T3 | + | T4 |) mientras que cualquier ORM o nonSQL tendrá que seguir repitiendo las consultas internas y dando lugar a una complejidad multiplicativa (| T1 | | T2 | | T3 | * | T4 |)

5 - tamaños de conjuntos de datos, escalabilidad no solo en tamaños de conjuntos de datos, sino también en el manejo de la concurrencia en las actualizaciones. Incluso los ORM-s que mantienen transacciones los hacen tan largos que las posibilidades de bloqueos aumentan exponencialmente.

6 - actualizaciones ciegas (muchos datos más tocados sin ninguna razón) y su dependencia y falla basadas en un instrumento ciego (versión mítica que es realista en, digamos, 1% del modelo de datos relacional pero ORM y alikes deben tener en todas partes)

7 - falta de estándares y compatibilidad - esto significa que su sistema y datos siempre estarán en mayor riesgo y dependerán de los cambios de software impulsados ​​por el aventurerismo académico en lugar de cualquier responsabilidad comercial real y con la expectativa de invertir una gran cantidad de recursos solo para probar los cambios.

8 - integridad de los datos: un código acaba de eliminar la mitad de los registros de pedidos actuales de T1 ya que no había una clave externa en T2 para detenerlo. Prefecly cosa normal que hacer con consultas separadas.

9 - madurez tendencia negativa - mantiene el astillado en vez de estandarizar - darle 20 años y tal vez va a conseguir estable

Por último, pero no menos importante - no reduce cualquier compexity (la misma correlación entre los datos sigue siendo allí), pero hace que sea muy difícil rastrear y administrar la complejidad o tener cualquier remedio realista o transparencia cuando algo sale mal. Y agrega la complejidad de 1-2 capas. Si algo sale mal en sus tablas SQL, tiene herramientas y consultas para descubrir e incluso corregir sus datos. ¿Qué vas a hacer cuando algún ORM simplemente te dice que tiene "puntero inválido" y arroja una excepción ya que seguramente no quieres "objeto inválido"?

Creo que es suficiente :-)

Answer 2

El hecho de que puede, no significa que debería.

la instrucción SELECT varias contras alternativas:

• los menos viajes al base de datos, mejor. No se puede recuperar la tara de TCP, y parece que la Neutralidad de red está oficialmente muerta, por lo que podríamos esperar ver un movimiento fuera de selección múltiple/nosql porque es posible que tenga que pagar ese ancho de banda ...
• debido a retraso entre declaraciones iniciales y posteriores, riesgo de datos que no reflejan lo que hay en el sistema cuando se ejecutó la primera consulta
• menos escalable: cuanto mayor sea el conjunto de datos, más trabajo hará la aplicación para manejar las reglas comerciales y la asociación que puede escalar mucho mejor en una base de datos
• más complejidad en la aplicación, lo que también hace que el negocio sea menos portátil (IE: migrar de Java a.NET o viceversa - lo que buscas en la construcción a partir de cero, cuando la lógica de negocio en la base de datos que minimizaría)

Answer 3

Usted podría NoSQL como una base de datos antigua usanza 'jerárquica' también!

Además de las respuestas de OMGPonies, informar es más difícil de hacer.

Acerca de la ampliación: eso no está bien. Nosql está pensado para escalar, si lo usas bien.

Otra razón para hacer nosql - si está haciendo todo su trabajo en objetos, yendo a la asignación de o-r a sql, y no funciona a través de instrucciones UPDATE complicadas (es decir, enrolladas a mano por eficiencia). por ejemplo, una actualización de una unión, o actualización 'donde ... en (...)'.

Si la base de datos es de propósito único (por ejemplo, el caso de las aplicaciones de gran volumen) nosql es más probable que esté bien.

Multipropósito - OLTP - Línea de negocios - ir con SQL.

Podría seguir, pero esto se está comiendo en mi hora del almuerzo. No es que alguna vez comiera en el trabajo. Prefiero solo comer durante mi almuerzo.

Answer 4

En realidad, uno de los mayores problemas es que algunas de las bases de datos NoSQL no son transaccionales entre múltiples consultas. ORM como Hibernate hará múltiples consultas sin "unirse" algunas veces, pero tienen la ventaja de que están en la misma transacción.

Con NoSQL no tiene ese lujo. así que esto podría muy fácilmente tener resultados engañosos:

SELECT * FROM user WHERE id = 4 
SELECT * FROM company WHERE id = {user.comany_id} 

Si se elimina la empresa para user.company_id de una llamada a los estados. Este es un problema bien conocido con estas bases de datos. Por lo tanto, independientemente de si usted puede o no hacer JOINs correctamente, el problema no será tener transacciones.

De lo contrario se puede modelar cualquier cosa con tal de que puede almacenar bytes :)