{"id":6386,"date":"2019-02-17T19:35:55","date_gmt":"2019-02-18T03:35:55","guid":{"rendered":"http:\/\/www.couchbase.com\/blog\/?p=6386"},"modified":"2025-06-13T17:22:10","modified_gmt":"2025-06-14T00:22:10","slug":"n1ql-query-with-self-referencing-hierarchy","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/n1ql-query-with-self-referencing-hierarchy\/","title":{"rendered":"Consulta N1QL con Jerarqu\u00eda Auto-referenciada"},"content":{"rendered":"

Una construcci\u00f3n de datos que aparece a menudo en las aplicaciones empresariales es la estructura jer\u00e1rquica de datos. La jerarqu\u00eda captura la relaci\u00f3n padre-hijo que a menudo existe entre el mismo objeto. Por ejemplo, la estructura de una empresa refleja la l\u00ednea jer\u00e1rquica entre los empleados. La organizaci\u00f3n empresarial captura la relaci\u00f3n entre empresas matrices y filiales. Jerarqu\u00edas territoriales en Ventas. Libro de cuentas en aplicaciones financieras.<\/p>\n

Debido a la naturaleza de auto-referencia de la jerarqu\u00eda, la consulta de la estructura de manera eficiente junto con sus datos asociados puede ser un reto para RDBMS, en particular desde una perspectiva de rendimiento. En este art\u00edculo, hablar\u00e9 de c\u00f3mo los SGBDR tradicionales gestionan las consultas jer\u00e1rquicas. Los retos con los que tiene que lidiar, y c\u00f3mo este problema puede ser abordado de manera similar con Couchbase N1QL y Couchbase GSI.<\/p>\n

Estructura jer\u00e1rquica en las aplicaciones<\/h2>\n

La principal raz\u00f3n para reunir la informaci\u00f3n en una estructura jer\u00e1rquica es mejorar la comprensi\u00f3n de la informaci\u00f3n. La estructura jer\u00e1rquica de la empresa est\u00e1 dise\u00f1ada no s\u00f3lo para ayudar a gestionar la organizaci\u00f3n, sino tambi\u00e9n para proporcionar una estructura que permita medir y optimizar la eficacia de cada grupo. En una gran organizaci\u00f3n, el rendimiento de las ventas suele evaluarse, no s\u00f3lo a nivel individual, sino a nivel de equipo de ventas. En resumen, las empresas organizan la informaci\u00f3n en una estructura jer\u00e1rquica para poder comprender mejor el rendimiento comercial. Para lograr ese objetivo, las empresas necesitan un medio eficaz para consultar los datos jer\u00e1rquicos.<\/p>\n

Representaci\u00f3n de la jerarqu\u00eda de la empresa<\/h3>\n

\"\"<\/p>\n

Aunque el modelo de datos de la base de datos es capaz de capturar eficazmente la estructura jer\u00e1rquica, la dificultad surge cuando es necesario consultar los datos jer\u00e1rquicos y la informaci\u00f3n relacionada.<\/p>\n

Considere este requisito:\u00a0<\/strong><\/span>Obtenga el valor total de los pedidos de venta de todos los representantes de ventas que dependen de ThomasH-Vicepresidente de Ventas.<\/strong><\/p>\n

\"\"<\/p>\n

Aunque el modelo de datos es relativamente sencillo. La naturaleza jer\u00e1rquica de la organizaci\u00f3n de ventas sugiere una estructura din\u00e1mica inherente en la jerarqu\u00eda de informes. AjayW, que dirige el territorio de la Regi\u00f3n1, tambi\u00e9n gestiona directamente a los miembros del equipo de ventas. Mientras que, en la Regi\u00f3n2, Liz L dirige a dos Gerentes, que a su vez dirigen al equipo de ventas. Esto es t\u00edpico en la mayor\u00eda de las jerarqu\u00edas de datos de aplicaci\u00f3n.<\/p>\n

Enfoque RDMBS<\/h4>\n

Para consultar datos jer\u00e1rquicos, los RDBMS m\u00e1s consolidados como Oracle y SQLSever proporcionan la construcci\u00f3n CONNECT BY \/ START WITH para permitir que una sola consulta recorra recursivamente la estructura de empleados de la jerarqu\u00eda.<\/p>\n

Query: Sales orders generated by members who report up to ThomasH-Sales VP<\/strong><\/span>\r\n\r\nSELECT e.EmpID, e.Name, e.ManagerID, sum(o.orderVal)\r\n   FROM employee e\r\n   INNER JOIN sales_order o ON o.EmpID = o.EmpId\r\n   START WITH EmpID = 101\r\n   CONNECT BY PRIOR EmpID = ManagerID\r\n   GROUP BY  e.EmpID, e.Name, e.ManagerID;\r\n\r\n<\/pre>\n
Aunque la consulta anterior puede parecer sencilla, el rendimiento de la consulta es dif\u00edcil de mejorar con \u00edndices debido a la naturaleza recursiva de la implementaci\u00f3n de CONNECT BY. Por este motivo, esta t\u00e9cnica no es popular en el desarrollo de aplicaciones para sistemas con un gran volumen de datos. En su lugar, las aplicaciones empresariales conf\u00edan en una estructura de objetos previamente aplanada para obtener un rendimiento de consulta m\u00e1s predecible. La t\u00e9cnica de jerarqu\u00eda aplanada se describe en la secci\u00f3n de Couchbase N1QL m\u00e1s abajo.<\/p>\n
Couchbase N1QL<\/h4>\n
Para obtener el mejor rendimiento de consulta, las aplicaciones N1QL deben utilizar la estructura jer\u00e1rquica aplanada. El enfoque proporciona un rendimiento m\u00e1s predecible, as\u00ed como un mejor aprovechamiento de Couchbase GSI. El diagrama de abajo muestra un ejemplo de la transformaci\u00f3n flattening de una estructura jer\u00e1rquica autorreferenciada, como el objeto empleado. Tambi\u00e9n incluyo un fragmento de c\u00f3digo python que puedes usar para aplanar la estructura jer\u00e1rquica.  El aplanar_jerarqu\u00eda<\/em><\/strong> toma un objeto JSON jer\u00e1rquico auto-referenciado y genera dos nuevos objetos en el mismo espacio de claves pero con diferentes valores de tipo<\/p>\n
\"\"<\/p>\n