récursive Query à l'aide HQL

Question

J'ai ce tableau

CREATE TABLE IF NOT EXISTS `branch` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `studcount` int(11) DEFAULT NULL, 
    `username` varchar(64) NOT NULL, 
    `branch_fk` int(11) DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    KEY `FKADAF25A2A445F1AF` (`branch_fk`), 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=14 ; 
ALTER TABLE `branch` 
    ADD CONSTRAINT `FKADAF25A24CEE7BFF` FOREIGN KEY (`login_fk`) REFERENCES `login` (`id`); 

que vous pouvez voir chaque table a une clé étrangère qui pointent vers d'autres Row Branch (auto de Relation) Je veux une aide de HQL (préfèrent HQL) à obtenir un nom d'utilisateur (ou id) de moi et retourner un List<String> (pour le nom d'utilisateur) ou List<Integer> (pour l'identification) qui était une liste de tous mes subBranch;

permettez-moi de montrer l'exemple

id   studentcount   username   branch_fk 
1   312      user01    NULL 
2   111      user02    1 
3   432      user03    1 
4   543      user04    2 
5   433      user05    3 
6   312      user06    5 
7   312      user06    2 
8   312      user06    7 

quand je l'appelle GetSubBranch (3) Je veux revenir:

5, 6 

et quand GetSubBranch d'appel (2) Je veux revenir:

4, 7, 8 

Answer 1

Je crois qu'il n'y a pas de SQL portable pour le faire. Encore plus, je pense que le SQL de plusieurs bases de données majeures ne peut pas exprimer cela. Par conséquent, cette fonctionnalité ne fait pas partie de ce que vous pouvez faire dans HQL. Je suis désolé :-(

Je lis quelques façons de procéder, la plupart d'entre elles impliquent des compromis en fonction du nombre de niveaux (fixé à l'avance, de combien?), Du nombre d'enregistrements (des centaines de millions?), Etc:

.

1. -ce que les requêtes récursives vous, nivellement par le bas à chaque fois (avec un in(ids)), jusqu'à un certain niveau est vide
2. Faites une requête avec un nombre fixe de gauche rejoint (la profondeur doivent être connus à l'avance; ou vous pourriez avoir besoin de répéter la requête pour trouver le reste des enregistrements si nécessaire, voir le point 1)
3. Avoir les informations dénormalisées disponible quelque part: il pourrait s'agir d'une copie de table dénormalisée des index. Mais je préférerais une copie en mémoire cachée, qui pourrait être complètement remplie en une seule requête, et être mise à jour ou invalidée ... en fonction de vos autres conditions requises, comme la taille de la table, la profondeur maximale, la fréquence d'écriture etc.

Answer 2

On peut jeter un coup d'œil aux 'ensembles imbriqués'. La recherche devient une question de 'entre: L et: R'. Mais le tri topologique/hiérarchique est perdu (par rapport aux requêtes récursives/hiérarchiques). L'insertion de nouveaux éléments est alors très coûteuse car elle nécessite des mises à jour sur plusieurs lignes sinon toutes ...