error de sintaxis de auto-unión en documentdb - join, azure-cosmosdb

Tengo problemas para realizar una consulta de autounión válida de SQL en documentdb.

Entonces la siguiente consulta funciona: SELECT * FROM c AS c1 WHERE c1.obj="car"

Pero esta simple consulta de autounión no: SELECT c1.url FROM c AS c1 JOIN c AS c2 WHERE c1.obj="car" AND c2.obj="person" AND c1.url = c2.url, con el error, Identifier "c" could not be resolved.

Parece que documendb admite autouniones dentro del documento, pero estoy preguntando a nivel de colección.

Miré al oficial documento de sintaxis y comprender que el nombre de la colección básicamente se infiere; Intenté cambiar c explícitamente el nombre de mi colección y la raíz, pero ninguno funcionó.

¿Me estoy perdiendo algo obvio? ¡Gracias!

Respuestas

1 para la respuesta № 1

Algunas cosas para aclarar:

1.) Respecto a Identifier "c" could not be resolved

Las consultas tienen como ámbito una sola colección; y en el ejemplo anterior, c es un alias implícito para la colección que se vuelve a alias a c1 con el AS palabra clave.

Puede corregir el cambio de consulta de ejemplo arreglando el JOIN para hacer referencia c1:

SELECT c1.url
FROM c AS c1
JOIN c1 AS c2
WHERE c1.obj="car" AND c2.obj="person" AND c1.url = c2.url`

Esto también es equivalente a:

SELECT c1.url
FROM c1
JOIN c1 AS c2
WHERE c1.obj="car" AND c2.obj="person" AND c1.url = c2.url`

2.) Comprender JOIN y examinar su modelo de datos

Dicho esto, no creo que solucionar el problema de sintaxis de consulta anterior produzca el comportamiento que espera. JOIN La palabra clave en DocumentDB SQL está diseñada para formarun producto cruzado con una matriz desnormalizada de elementos dentro de un documento (en lugar de formar productos cruzados en otros documentos de la misma colección). Si tiene dificultades aquí, puede valer la pena dar un paso atrás y volver a revisar cómo modelar sus datos para Azure Cosmos DB.

En un RDBMS, está capacitado para pensar en la entidad primeroy normalice su modelo de datos basado en entidades. Depende en gran medida de un motor de consultas para optimizar las consultas y adaptarlas a su carga de trabajo (que normalmente hace un buen trabajo, pero no siempre óptimo, para recuperar datos). Los desafíos aquí son que muchos beneficios relacionales se pierden a medida que aumenta la escala, y el escalado horizontal a múltiples fragmentos / particiones se convierte en un requisito.

Para una base de datos distribuida escalable como CosmosDB, primero querrá comenzar por comprender la carga de trabajo y optimizar su modelo de datos para que se ajuste a la carga de trabajo (en lugar de pensar primero en la entidad). Deberá tener en cuenta que las colecciones son simplemente una abstracción lógica compuesta por muchas réplicas que viven dentro de los conjuntos de particiones. No imponen el esquema y son el límite para las consultas.

Al diseñar su modelo, querrá incorporar las siguientes preguntas en su proceso de pensamiento:

• ¿Cuál es la escala, en términos de tamaño y rendimiento, para la solución más amplia (una estimación del orden de magnitud es suficiente)?

• ¿Cuál es la proporción de lecturas frente a escrituras?

• Para las escrituras, ¿cuál es el patrón para las escrituras? ¿Se trata principalmente de inserciones o hay muchas actualizaciones?

• Para lecturas, ¿cómo se ven las N consultas principales?

Lo anterior debería influir en su elección de la clave de partición, así como en el aspecto que debería tener su modelo de datos / objetos. Por ejemplo:

• La proporción de solicitudes ayudará a orientar la forma en que realiza las compensaciones (use el principio de Pareto y optimice la mayor parte de su carga de trabajo).
• Para cargas de trabajo de gran lectura, las propiedades filtradas comúnmente se convierten en candidatas para la elección de la clave de partición.
• Propiedades que tienden a actualizarse juntascon frecuencia deben abstraerse juntos en el modelo de datos, y lejos de las propiedades que se actualizan con una cadencia más lenta (para reducir el cargo de RU por las actualizaciones).
• No tenga miedo de duplicar propiedades para enriquecer la capacidad de consulta y anotar tipos en diferentes tipos de registros. Por ejemplo, tenemos dos tipos de documentos: cat y person.

    {
"id": "Andrew",
"type": "Person",
"familyId": "Liu",
"employer": "Microsoft"
}

{
"id": "Ralph",
"type": "Cat",
"familyId": "Liu",
"fur": {
"length": "short",
"color": "brown"
}
}

Podemos consultar ambos tipos de documentos sin necesidad de un JOIN simplemente ejecutando una consulta sin un filtro de tipo:

SELECT * FROM c WHERE c.familyId = "Liu"

Y si quisiéramos filtrar por tipo = "Persona", simplemente podemos agregar un filtro por tipo a nuestra consulta:

SELECT * FROM c WHERE c.familyId = "Liu" AND c.type = "Person"

---