Итак, я сделал массивный выбор на MySQL и получил много данных, упорядоченных по индексу.
Например:
select * from nodes where config_id = 1;
Дает (показаны только релевантности)
| definition_id (PK) | position | parent |
-------------------------------------------
90 1 0 << "root"
08 2 0
34 3 0
22 4 0
17 1 7 << another defn_id
38 2 7
23 3 7
07 1 90
Если это не имеет смысла, представьте себе определение дерева, где 90, 8, 34 и 22 являются потомками корня.
7 - это потомок 90, а 17, 38, 23 -дети 7 лет (внуки корня).
Чтобы обработать это, мы находим все узлы с родительским 0, добавляем их, затем просматриваем все эти узлы, проверяем, есть ли у них дочерние элементы (отбирая их у родителя или не видя значений).и рассматривая это как лист).Если у них есть дети, добавьте их и продолжайте рекурсивно до тех пор, пока не будет построено дерево.
Это не самое эффективное хранилище данных, но одно из требований - это «изменение одной строки» для перемещения подмножестваузлы и все дети.Я бы лучше определил строку 0.1.6 и т. Д., Но так оно и есть.
Так что в тестировании это работает довольно хорошо, но когда нам нужно делать это 100 000 раз в день (без кеширования - нет смысла, все немного по-другому) - нам нужно сделать это с минимальным количеством обращений к базе данных, каквозможно (т.е. ОДИН).Легко, вы говорите, просто захватите всю партию и обработайте.Но, они не все порядок - как вы можете видеть выше, 90 ниже 7. Да, эти примеры потворствовали, но это иллюстрирует проблему, что нам нужен какой-то порядок.
По сути, в двух словах, вопрос заключается в том, является ли их простой (и, предпочтительно, дешевый) способ сделать дополнительный выбор в ResultSet - т.е. захватить все результаты, где parent == 7, в другой ResultSet и работатьна что?
Вечная любовь и благодарность в обмен на мысли / комментарии.