{"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\/pt\/query-graph-recursive-cte\/","title":{"rendered":"Modelos de gr\u00e1ficos de consulta com CTE recursivo do Couchbase"},"content":{"rendered":"

As express\u00f5es de tabela comum (CTEs) recursivas e o CONNECT BY do Oracle s\u00e3o constru\u00e7\u00f5es SQL bem conhecidas entre os usu\u00e1rios de RDBMS, facilitando a delega\u00e7\u00e3o da explora\u00e7\u00e3o de estruturas de dados complexas e interdependentes \u00e0 camada de banco de dados para aumentar a efici\u00eancia do processamento.<\/span><\/p>\n

Essas constru\u00e7\u00f5es s\u00e3o essenciais para a consulta de estruturas de dados interdependentes, um requisito comum em v\u00e1rios setores, incluindo finan\u00e7as, gerenciamento da cadeia de suprimentos, gerenciamento de relacionamento com o cliente (CRM), reservas de viagens e, mais recentemente, redes sociais. Reconhecendo sua import\u00e2ncia, todos os principais sistemas de gerenciamento de bancos de dados relacionais (RDBMS), como PostgreSQL, MySQL (a partir da vers\u00e3o 8.0), SQL Server, Oracle e SQLite, oferecem suporte a CTEs recursivos.<\/span><\/p>\n

Por outro lado, os bancos de dados NoSQL, que s\u00e3o projetados para gerenciar uma s\u00e9rie diversificada de modelos de dados, como documentos, valores-chave, colunas amplas e dados de gr\u00e1ficos, priorizam a escalabilidade, a alta disponibilidade, a flexibilidade e o desempenho em sistemas distribu\u00eddos. Nesses ambientes, o conceito de CTE, recursivo ou n\u00e3o, n\u00e3o \u00e9 abordado diretamente. Os usu\u00e1rios geralmente recorrem a solu\u00e7\u00f5es especializadas, como bancos de dados de gr\u00e1ficos - Cypher para Neo4J e AQL para ArangoDB, por exemplo - para lidar com estruturas de dados complexas.<\/span><\/p>\n

O Couchbase se diferencia com o SQL para JSON, oferecendo uma abordagem exclusiva para CTEs recursivos que tamb\u00e9m ampliam seu suporte a v\u00e1rios modelos. Este blog se aprofundar\u00e1 em tr\u00eas t\u00f3picos principais:<\/span><\/p>\n

    \n
  1. \n
      \n
    1. Como voc\u00ea pode aproveitar um \u00fanico DBMS como o Couchbase para estruturas de dados complexas para v\u00e1rios casos de uso, da mesma forma que o RDBMS, mas sem a necessidade de um banco de dados mais dedicado.\u00a0<\/span><\/li>\n
    2. O uso da constru\u00e7\u00e3o Couchase SQL++ para consultar, transformar e projetar essas rela\u00e7\u00f5es complexas usando uma constru\u00e7\u00e3o SQL que \u00e9 familiar aos usu\u00e1rios de RDBMS.<\/span><\/li>\n
    3. Pr\u00e1ticas recomendadas para gerenciar o consumo de recursos com o CTE recursivo.<\/span><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

      Caso de uso da lista de materiais<\/span><\/h2>\n

      A lista t\u00e9cnica \u00e9 um componente essencial na fabrica\u00e7\u00e3o e na engenharia, detalhando as mat\u00e9rias-primas, pe\u00e7as e componentes necess\u00e1rios para fabricar um produto. Ela geralmente tem uma estrutura hier\u00e1rquica, em que as pe\u00e7as s\u00e3o compostas de outras pe\u00e7as ou materiais.<\/span><\/p>\n

      Este exemplo incluir\u00e1 os componentes e subcomponentes b\u00e1sicos de um computador desktop.<\/span><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
      ID do componente<\/b><\/td>\nComponentName<\/b><\/td>\nParentComponentID<\/b><\/td>\nQuantidade<\/b><\/td>\n<\/tr>\n
      1<\/span><\/td>\nComputador de mesa<\/span><\/td>\nnulo<\/span><\/td>\n1<\/span><\/td>\n<\/tr>\n
      2<\/span><\/td>\nPlaca-m\u00e3e<\/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 da 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>\nUnidade 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>\nFonte de alimenta\u00e7\u00e3o<\/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 resfriamento do gabinete<\/span><\/td>\n1<\/span><\/td>\n4<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Digamos que queremos listar todas as pe\u00e7as e subpe\u00e7as necess\u00e1rias para montar um computador desktop, juntamente com as quantidades necess\u00e1rias para cada uma delas.<\/span><\/p>\n

      WITH RECURSIVE ComponentHierarchy AS (\r\n    SELECT\r\n        ComponentID,\r\n        ComponentName,\r\n        ParentComponentID,\r\n        Quantity,\r\n        1 AS Lvl -- N\u00edvel de profundidade na hierarquia\r\n    DE\r\n        componentes\r\n    WHERE\r\n        ParentComponentID IS NULL -- Ponto de partida: o pr\u00f3prio computador desktop\r\n\r\n    UNION ALL\r\n\r\n    SELECT\r\n        c.ComponentID,\r\n        c.ComponentName,\r\n        c.ParentComponentID,\r\n        ch.Quantity * c.Quantity AS Quantity, -- Calcular a quantidade total necess\u00e1ria em cada n\u00edvel\r\n        ch.lvl + 1 -- Incrementa o n\u00edvel para cada etapa de recurs\u00e3o\r\n    DE\r\n        componentes c\r\n    JOIN\r\n        ComponentHierarchy ch ON c.ParentComponentID = ch.ComponentID\r\n)\r\nSELECT * FROM ComponentHierarchy;<\/pre>\n
      Essa consulta inicializa a recurs\u00e3o com o item de n\u00edvel superior (o computador de mesa) e junta recursivamente a tabela de componentes com ela mesma para percorrer a hierarquia, ajustando as quantidades conforme necess\u00e1rio para cada componente e subcomponente.<\/span><\/p>\n
      O resultado listar\u00e1 todas as pe\u00e7as necess\u00e1rias para o computador de mesa, incluindo a quantidade de cada uma e seu n\u00edvel hier\u00e1rquico, o que pode ser \u00fatil para entender a estrutura de montagem ou para fins de invent\u00e1rio e pedido.<\/span><\/p>\n
      Explica\u00e7\u00e3o<\/span><\/h3>\n
      O CTE come\u00e7a com o Bicycle (onde ParentPartID \u00e9 NULL) e, em seguida, procura recursivamente todos os componentes e subcomponentes.<\/span><\/p>\n
      A quantidade \u00e9 ajustada em cada n\u00edvel para refletir o n\u00famero total necess\u00e1rio para uma bicicleta.<\/span><\/p>\n
      A coluna N\u00edvel, embora n\u00e3o seja estritamente necess\u00e1ria para todas as an\u00e1lises de lista t\u00e9cnica, ajuda a entender a profundidade de cada pe\u00e7a na hierarquia.<\/span><\/p>\n
      Essa abordagem permite uma an\u00e1lise detalhada de todos os materiais e componentes necess\u00e1rios para a fabrica\u00e7\u00e3o de um produto, o que \u00e9 essencial para o gerenciamento de estoque, a estimativa de custos e o planejamento da produ\u00e7\u00e3o nas opera\u00e7\u00f5es de fabrica\u00e7\u00e3o.<\/span><\/p>\n
      Caso de uso de rede social<\/span><\/h2>\n
      Uma aplica\u00e7\u00e3o comum em um caso de uso de rede social \u00e9 encontrar os graus de conex\u00e3o entre dois usu\u00e1rios - essencialmente, como os usu\u00e1rios est\u00e3o conectados por meio de uma cadeia de amigos em comum. Digamos que precisamos determinar o caminho mais curto (em termos de graus de conex\u00e3o) entre dois usu\u00e1rios em uma rede social. Isso pode ajudar em recursos como a sugest\u00e3o de amizades ou a compreens\u00e3o da din\u00e2mica da rede.<\/span><\/p>\n
      Considere que temos os seguintes usu\u00e1rios e como eles s\u00e3o amigos uns dos outros, por exemplo, Alice \u00e9 amiga de Bob e tamb\u00e9m de Charlie. Mas Alice n\u00e3o \u00e9 amiga de Dana.<\/span><\/p>\n

      \"\"

      <\/p>\n
      Nessa rede expandida, os usu\u00e1rios s\u00e3o conectados de v\u00e1rias maneiras, criando v\u00e1rios caminhos pelos quais os usu\u00e1rios podem se conectar.<\/span><\/p>\n
      Vamos encontrar os graus de conex\u00e3o entre Alice[1] e Frank[6], incluindo os nomes dos usu\u00e1rios ao longo do caminho.<\/span><\/p>\n
      WITH RECURSIVE ConnectionPath AS (\r\n    SELECT\r\n        u1.UserID,\r\n        u1.UserName AS StartUser,\r\n        u2.UserID AS FriendID,\r\n        u2.UserName AS FriendName,\r\n        1 AS Degree\r\n    DE\r\n        conex\u00f5es_de_usu\u00e1rio uc\r\n    JOIN\r\n        users u1 ON uc.UserID = u1.UserID\r\n    JOIN\r\n        usu\u00e1rios u2 ON uc.FriendID = u2.UserID\r\n    WHERE\r\n        u1.UserID = 1 -- Usu\u00e1rio inicial (Alice)\r\n    \r\n    UNION ALL\r\n    \r\n    SELECT\r\n        cp.UserID,\r\n        cp.StartUser,\r\n        u.UserID AS FriendID,\r\n        u.UserName AS FriendName,\r\n        cp.Degree + 1\r\n    DE\r\n        ConnectionPath cp\r\n    JOIN\r\n        user_connections uc ON cp.FriendID = uc.UserID\r\n    JOIN\r\n        usu\u00e1rios u ON uc.FriendID = u.UserID\r\n    WHERE\r\n        uc.FriendID NOT IN (cp.UserID) -- Evite loops ao n\u00e3o revisitar o usu\u00e1rio inicial\r\n)\r\nSELECT * FROM ConnectionPath\r\nWHERE FriendID = 6 -- Usu\u00e1rio-alvo (Frank)\r\nORDER BY Degree ASC;<\/pre>\n
      Explica\u00e7\u00e3o<\/span><\/h3>\n