{"id":15705,"date":"2024-05-09T10:03:54","date_gmt":"2024-05-09T17:03:54","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=15705"},"modified":"2024-05-22T13:47:54","modified_gmt":"2024-05-22T20:47:54","slug":"query-graph-recursive-cte","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/query-graph-recursive-cte\/","title":{"rendered":"Consulta de modelos gr\u00e1ficos con CTE recursivo de Couchbase"},"content":{"rendered":"

Las expresiones comunes de tabla (CTE) recursivas y CONNECT BY de Oracle son construcciones SQL muy conocidas entre los usuarios de RDBMS, que facilitan la delegaci\u00f3n de la exploraci\u00f3n de estructuras de datos complejas e interdependientes a la capa de base de datos para mejorar la eficacia del procesamiento.<\/span><\/p>\n

Estas construcciones son cruciales para consultar estructuras de datos interdependientes, un requisito com\u00fan en varios sectores, como las finanzas, la gesti\u00f3n de la cadena de suministro, la gesti\u00f3n de las relaciones con los clientes (CRM), las reservas de viajes y, m\u00e1s recientemente, las redes sociales. Conscientes de su importancia, los principales sistemas de gesti\u00f3n de bases de datos relacionales (RDBMS), como PostgreSQL, MySQL (a partir de la versi\u00f3n 8.0), SQL Server, Oracle y SQLite, ofrecen soporte para CTE recursivas.<\/span><\/p>\n

Por el contrario, las bases de datos NoSQL, dise\u00f1adas para gestionar una amplia gama de modelos de datos como documentos, datos clave-valor, de columnas anchas y gr\u00e1ficos, dan prioridad a la escalabilidad, la alta disponibilidad, la flexibilidad y el rendimiento en sistemas distribuidos. En estos entornos, el concepto de CTE, recursivo o no, no se aborda directamente. Los usuarios suelen recurrir a soluciones especializadas, como las bases de datos de grafos (Cypher para Neo4J y AQL para ArangoDB, por ejemplo), para gestionar estructuras de datos complejas.<\/span><\/p>\n

Couchbase se distingue con SQL para JSON, ofreciendo un enfoque \u00fanico a CTEs recursivos que tambi\u00e9n extienden su soporte multi modelo. Este blog profundizar\u00e1 en tres temas principales:<\/span><\/p>\n

    \n
  1. \n
      \n
    1. C\u00f3mo se puede aprovechar un \u00fanico DBMS como Couchbase para estructuras de datos complejas para una serie de casos de uso, de la misma manera que RDBMS podr\u00eda, pero sin la necesidad de una base de datos m\u00e1s dedicada.\u00a0<\/span><\/li>\n
    2. El uso del constructo Couchase SQL++ para consultar, transformar y proyectar estas relaciones complejas utilizando un constructo SQL que es familiar a los usuarios de RDBMS.<\/span><\/li>\n
    3. Mejores pr\u00e1cticas para gestionar el consumo de recursos con CTE recursivo.<\/span><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

      Lista de materiales<\/span><\/h2>\n

      La lista de materiales es un componente fundamental en la fabricaci\u00f3n y la ingenier\u00eda, ya que detalla las materias primas, las piezas y los componentes necesarios para fabricar un producto. Suele tener una estructura jer\u00e1rquica, en la que las piezas se componen de otras piezas o materiales.<\/span><\/p>\n

      Este ejemplo incluir\u00e1 los componentes y subcomponentes b\u00e1sicos de un ordenador de sobremesa.<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
      Componente ID<\/b><\/td>\nComponentName<\/b><\/td>\nParentComponentID<\/b><\/td>\nCantidad<\/b><\/td>\n<\/tr>\n
      1<\/span><\/td>\nOrdenador de sobremesa<\/span><\/td>\nnull<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      2<\/span><\/td>\nPlaca base<\/span><\/td>\n1<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      3<\/span><\/td>\nCPU<\/span><\/td>\n2<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      3<\/span><\/td>\nVentilador de la CPU<\/span><\/td>\n3<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      4<\/span><\/td>\nGPU<\/span><\/td>\n2<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      5<\/span><\/td>\nRAM<\/span><\/td>\n2<\/span><\/td>\n4<\/span><\/td>\n<\/tr>\n
      6<\/span><\/td>\nUnidad M.2<\/span><\/td>\n2<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      7<\/span><\/td>\nSSD<\/span><\/td>\n2<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      8<\/span><\/td>\nFuente de alimentaci\u00f3n<\/span><\/td>\n1<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      9<\/span><\/td>\nCaso<\/span><\/td>\n1<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      10<\/span><\/td>\nVentiladores de refrigeraci\u00f3n de la carcasa<\/span><\/td>\n1<\/span><\/td>\n4<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Supongamos que queremos enumerar todas las piezas y subpiezas necesarias para construir un ordenador de sobremesa, junto con las cantidades necesarias de cada una.<\/span><\/p>\n

      WITH RECURSIVE ComponentHierarchy AS (\r\n\u00a0 \u00a0 SELECT\r\n\u00a0 \u00a0 \u00a0 \u00a0 ComponentID,\r\n\u00a0 \u00a0 \u00a0 \u00a0 ComponentName,\r\n\u00a0 \u00a0 \u00a0 \u00a0 ParentComponentID,\r\n\u00a0 \u00a0 \u00a0 \u00a0 Quantity,\r\n\u00a0 \u00a0 \u00a0 \u00a0 1 AS Lvl -- Depth level in the hierarchy\r\n\u00a0 \u00a0 FROM\r\n\u00a0 \u00a0 \u00a0 \u00a0 components\r\n\u00a0 \u00a0 WHERE\r\n\u00a0 \u00a0 \u00a0 \u00a0 ParentComponentID IS NULL -- Starting point: the Desktop Computer itself\r\n\r\n\u00a0 \u00a0 UNION ALL\r\n\r\n\u00a0 \u00a0 SELECT\r\n\u00a0 \u00a0 \u00a0 \u00a0 c.ComponentID,\r\n\u00a0 \u00a0 \u00a0 \u00a0 c.ComponentName,\r\n\u00a0 \u00a0 \u00a0 \u00a0 c.ParentComponentID,\r\n\u00a0 \u00a0 \u00a0 \u00a0 ch.Quantity * c.Quantity AS Quantity, -- Calculate total quantity required at each level\r\n\u00a0 \u00a0 \u00a0 \u00a0 ch.lvl + 1 -- Increment level for each recursion step\r\n\u00a0 \u00a0 FROM\r\n\u00a0 \u00a0 \u00a0 \u00a0 components c\r\n\u00a0 \u00a0 JOIN\r\n\u00a0 \u00a0 \u00a0 \u00a0 ComponentHierarchy ch ON c.ParentComponentID = ch.ComponentID\r\n)\r\nSELECT * FROM ComponentHierarchy;<\/pre>\n
      Esta consulta inicializa la recursi\u00f3n con el elemento de nivel superior (el ordenador de sobremesa) y une recursivamente la tabla de componentes consigo misma para recorrer la jerarqu\u00eda en sentido descendente, ajustando las cantidades seg\u00fan sea necesario para cada componente y subcomponente.<\/span><\/p>\n
      El resultado listar\u00e1 todas las piezas necesarias para el Ordenador de Sobremesa, incluyendo la cantidad de cada una y su nivel jer\u00e1rquico, lo que puede ser \u00fatil para entender la estructura de ensamblaje o para fines de inventario y pedidos.<\/span><\/p>\n
      Explicaci\u00f3n<\/span><\/h3>\n
      El CTE comienza con la Bicicleta (donde ParentPartID es NULL) y luego busca recursivamente todos los componentes y subcomponentes.<\/span><\/p>\n
      La cantidad se ajusta en cada nivel para reflejar el n\u00famero total necesario para una bicicleta.<\/span><\/p>\n
      La columna Nivel, aunque no es estrictamente necesaria para todos los an\u00e1lisis de listas de materiales, ayuda a comprender la profundidad de cada pieza dentro de la jerarqu\u00eda.<\/span><\/p>\n
      Este enfoque permite un desglose detallado de todos los materiales y componentes necesarios para fabricar un producto, esencial para la gesti\u00f3n de inventarios, la estimaci\u00f3n de costes y la planificaci\u00f3n de la producci\u00f3n en las operaciones de fabricaci\u00f3n.<\/span><\/p>\n
      Redes sociales<\/span><\/h2>\n
      Una aplicaci\u00f3n com\u00fan en un caso de uso de redes sociales es encontrar los grados de conexi\u00f3n entre dos usuarios -esencialmente, c\u00f3mo est\u00e1n conectados los usuarios a trav\u00e9s de una cadena de amigos comunes. Digamos que necesitamos determinar el camino m\u00e1s corto (en t\u00e9rminos de grados de conexi\u00f3n) entre dos usuarios en una red social. Esto puede ayudar en funciones como sugerir amistades o comprender la din\u00e1mica de la red.<\/span><\/p>\n
      Consideremos que tenemos los siguientes usuarios y c\u00f3mo son amigos entre s\u00ed, por ejemplo, Alice es amiga de Bob, y tambi\u00e9n de Charlie. Pero Alice no es amiga de Dana.<\/span><\/p>\n

      \"\"

      <\/p>\n
      En esta red ampliada, los usuarios se conectan de diversas maneras, creando m\u00faltiples v\u00edas a trav\u00e9s de las cuales pueden conectarse.<\/span><\/p>\n
      Vamos a encontrar los grados de conexi\u00f3n entre Alice[1] y Frank[6], incluyendo los nombres de los usuarios a lo largo del camino.<\/span><\/p>\n
      WITH RECURSIVE ConnectionPath AS (\r\n\u00a0 \u00a0 SELECT\r\n\u00a0 \u00a0 \u00a0 \u00a0 u1.UserID,\r\n\u00a0 \u00a0 \u00a0 \u00a0 u1.UserName AS StartUser,\r\n\u00a0 \u00a0 \u00a0 \u00a0 u2.UserID AS FriendID,\r\n\u00a0 \u00a0 \u00a0 \u00a0 u2.UserName AS FriendName,\r\n\u00a0 \u00a0 \u00a0 \u00a0 1 AS Degree\r\n\u00a0 \u00a0 FROM\r\n\u00a0 \u00a0 \u00a0 \u00a0 user_connections uc\r\n\u00a0 \u00a0 JOIN\r\n\u00a0 \u00a0 \u00a0 \u00a0 users u1 ON uc.UserID = u1.UserID\r\n\u00a0 \u00a0 JOIN\r\n\u00a0 \u00a0 \u00a0 \u00a0 users u2 ON uc.FriendID = u2.UserID\r\n\u00a0 \u00a0 WHERE\r\n\u00a0 \u00a0 \u00a0 \u00a0 u1.UserID = 1 -- Starting user (Alice)\r\n\u00a0 \u00a0 \r\n\u00a0 \u00a0 UNION ALL\r\n\u00a0 \u00a0 \r\n\u00a0 \u00a0 SELECT\r\n\u00a0 \u00a0 \u00a0 \u00a0 cp.UserID,\r\n\u00a0 \u00a0 \u00a0 \u00a0 cp.StartUser,\r\n\u00a0 \u00a0 \u00a0 \u00a0 u.UserID AS FriendID,\r\n\u00a0 \u00a0 \u00a0 \u00a0 u.UserName AS FriendName,\r\n\u00a0 \u00a0 \u00a0 \u00a0 cp.Degree + 1\r\n\u00a0 \u00a0 FROM\r\n\u00a0 \u00a0 \u00a0 \u00a0 ConnectionPath cp\r\n\u00a0 \u00a0 JOIN\r\n\u00a0 \u00a0 \u00a0 \u00a0 user_connections uc ON cp.FriendID = uc.UserID\r\n\u00a0 \u00a0 JOIN\r\n\u00a0 \u00a0 \u00a0 \u00a0 users u ON uc.FriendID = u.UserID\r\n\u00a0 \u00a0 WHERE\r\n\u00a0 \u00a0 \u00a0 \u00a0 uc.FriendID NOT IN (cp.UserID) -- Avoid loops by not revisiting the start user\r\n)\r\nSELECT * FROM ConnectionPath\r\nWHERE FriendID = 6 -- Target user (Frank)\r\nORDER BY Degree ASC;<\/pre>\n
      Explicaci\u00f3n<\/span><\/h3>\n