http://www.chicoree.fr/w/Requ%C3%AAtes_r%C3%A9cursives_avec_Derbyhttp://www.chicoree.fr/w/Requ%C3%AAtes_r%C3%A9cursives_avec_Derby#Le_probl.C3.A8meAprès cette introduction qui a peut-être soulevée plus de questions qu'elle n'a apporté de réponses, prenons quelques instants pour examiner un cas typique de ce genre de problème. Considérons le groupe de grande distribution Système Z. Ce groupe possède des magasins affiliés en France et en Europe. Au gré de l'évolution du groupe et de l'affiliation de nouveaux magasins, ceux-ci se sont vus rattachés à des zones. Celles-ci peuvent être à l'échelle d'une ville, d'une région voire même d'un pays. Le groupement en zone permet de centraliser les approvisionnements et participe à la gestion administrative de la chaîne de magasins, tout en permettant une relative autonomie et suffisamment de souplesse pour s'adapter aux besoins du marché local. Çà, c'était pour les arguments commerciaux.

]]>http://www.chicoree.fr/w/Requ%C3%AAtes_r%C3%A9cursives_avec_Derby#Requ.C3.AAtes_r.C3.A9cursives_en_JavaOr donc, la solution réside dans le monde Java. Parce que Derby permet de définir nos propres fonctions-tables (table functions – ou tables virtuelles). Késako? Et bien ce sont des fonctions Java dont le résultat est une table. Autrement dit encore, des fonctions dont le résultat peut servir comme une table ordinaire. Et dont le résultat peut donc être exploité par la machinerie SQL dans une requête SELECT. Pour plus de renseignement sur ce sujet, je vous engage à lire l'article Tables virtuelles sous Derby. En deux mots, il s'agit d'écrire une méthode Java qui renvoit une instance de ResultSet, afin que Derby puisse manipuler ces données comme une table.

]]>http://www.chicoree.fr/w/Requ%C3%AAtes_r%C3%A9cursives_avec_Derby#Fonctions-tablesOr donc, la solution réside dans le monde Java. Parce que Derby permet de définir nos propres fonctions-tables (table functions – ou tables virtuelles). Késako? Et bien ce sont des fonctions Java dont le résultat est une table. Autrement dit encore, des fonctions dont le résultat peut servir comme une table ordinaire. Et dont le résultat peut donc être exploité par la machinerie SQL dans une requête SELECT. Pour plus de renseignement sur ce sujet, je vous engage à lire l'article Tables virtuelles sous Derby. En deux mots, il s'agit d'écrire une méthode Java qui renvoit une instance de ResultSet, afin que Derby puisse manipuler ces données comme une table.

]]>http://www.chicoree.fr/w/Requ%C3%AAtes_r%C3%A9cursives_avec_Derby#Recursive_ou_it.C3.A9rativeEn fait, si en SQL nous aurions besoin de requêtes récursives à cause de la nature déclarative de ce langage, comme Java est un langage impératif, il devient possible d'utiliser une itération à la place.

]]>http://www.chicoree.fr/w/Requ%C3%AAtes_r%C3%A9cursives_avec_Derby#ConclusionPour terminer, un petit avertissement: ce n'est pas parce qu'on peut le faire qu'il faut le faire! Ainsi, si nous avons vu qu'il était possible avec Derby d'écrire une fonction table qui permet d'explorer une structure arborescente définie par une liste d'adjascence, ça n'est pas forcément la panacée. En effet, vous comprenez que cela implique l'exécution d'un certain nombre de requête par le SGBD. Même si ces requêtes sont cachées dans le code Java. Au final, cela peut devenir d'autant plus pénalisant, que la profondeur de l'arbre est importante. Par contre, là où les listes d'adjascence sont imbattables, c'est au niveau de l'ajout: Puisqu'une seule requête est nécessaire.

]]>http://www.chicoree.fr/w/Requ%C3%AAtes_r%C3%A9cursives_avec_Derby#R.C3.A9f.C3.A9rences