SQL falla en 3+ saltos. GraphDBs no. Imagina encontrar todas las cuentas dentro de 3 saltos de una transacción sospechosa. O vincular registros de clientes fragmentados a través de sistemas por correos electrónicos y números de teléfono compartidos. Estas son consultas de recorrido de grafos. SQL puede manejar relaciones pero no profundidad. Claro, puedes escribir CTEs recursivos y auto-uniones. Eso funciona en 1-2 saltos. Pero si profundizas, suceden dos cosas: - La consulta se vuelve ilegible - Y el rendimiento se desploma Cada salto añade otra auto-unión. Para el salto 5-6, estás viendo consultas que tardan minutos y se desmoronan bajo carga. La misma consulta en Cypher: 𝗠𝗔𝗧𝗖𝗛 (𝘁:𝗧𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 {𝗶𝗱: '𝗧𝗫𝗡-𝟬𝟬𝟭'})-[:𝗜𝗡𝗩𝗢𝗟𝗩𝗘𝗦*𝟭..𝟯]-(𝗮:𝗔𝗰𝗰𝗼𝘂𝗻𝘁) 𝗥𝗘𝗧𝗨𝗥𝗡 𝗗𝗜𝗦𝗧𝗜𝗡𝗖𝗧 𝗮.𝗻𝗮𝗺𝗲, 𝗮.𝗽𝗵𝗼𝗻𝗲 3 líneas. Se lee como la pregunta que estás haciendo. Escala a cualquier profundidad. Esto es para lo que están construidas las bases de datos de grafos. FalkorDB es una que vale la pena conocer. Es de código abierto. Y toma un enfoque arquitectónico diferente en comparación con la mayoría de las bases de datos de grafos. La mayoría de las bases de datos de grafos persiguen punteros de nodo a nodo durante el recorrido. FalkorDB no hace eso. Está construido sobre GraphBLAS, un marco de álgebra lineal que representa operaciones de grafos como cálculos de matrices dispersas. Cada salto se convierte en una operación de matriz optimizada en su lugar. El resultado: - Mejor comportamiento de caché - Cálculo paralelo a través de saltos...