SQL échoue à 3+ sauts. Les GraphDB ne le font pas. Imaginez trouver tous les comptes dans un rayon de 3 sauts d'une transaction suspecte. Ou lier des enregistrements clients fragmentés à travers des systèmes par des emails et des numéros de téléphone partagés. Ce sont des requêtes de parcours de graphe. SQL peut gérer les relations mais pas la profondeur. Bien sûr, vous pouvez écrire des CTE récursifs et des auto-joints. Cela fonctionne à 1-2 sauts. Mais allez plus loin et deux choses se produisent : - La requête devient illisible - Et la performance s'effondre Chaque saut ajoute un autre auto-joint. Au saut 5-6, vous regardez des requêtes qui s'exécutent pendant des minutes et s'effondrent sous la charge. La même requête en Cypher : 𝗠𝗔𝗧𝗖𝗛 (𝘁:𝗧𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 {𝗶𝗱: '𝗧𝗫𝗡-𝟬𝟬𝟭'})-[:𝗜𝗡𝗩𝗢𝗟𝗩𝗘𝗦*𝟭..𝟯]-(𝗮:𝗔𝗰𝗰𝗼𝘂𝗻𝘁) 𝗥𝗘𝗧𝗨𝗥𝗡 𝗗𝗜𝗦𝗧𝗜𝗡𝗖𝗧 𝗮.𝗻𝗮𝗺𝗲, 𝗮.𝗽𝗵𝗼𝗻𝗲 3 lignes. Se lit comme la question que vous posez. S'échelonne à n'importe quelle profondeur. C'est pour cela que les bases de données graphiques sont conçues. FalkorDB est une à connaître. C'est open-source. Et il adopte une approche architecturale différente par rapport à la plupart des Graph DB. La plupart des bases de données graphiques poursuivent des pointeurs de nœud à nœud lors du parcours. FalkorDB ne fait pas cela. Il est construit sur GraphBLAS, un cadre d'algèbre linéaire qui représente les opérations de graphe comme des calculs de matrices creuses. Chaque saut devient une opération de matrice optimisée à la place. Le résultat : - Meilleur comportement de cache - Calcul parallèle à travers les sauts...