2015-07-29 3 views
1

В этомПочему в этом поиске B-Tree есть два листовых узла?

enter image description here

графика, мы смотрим вверх EMPLOYEE_ID 123 и subsidary_id 20 в B-Tree (из учебника по индексам базы данных). Есть два листовых узла, ветвящихся с дерева. Является ли это чисто демонстрацией или есть что-то, что мне не хватает, поскольку я думаю, что единственный листовой узел, который должен быть проверен, будет верхним, так как он имеет employee_id max 123 и secondaryary_id max. 27.

+0

Erm, как насчет узлов, которые не являются * 123? Разве вы не собираетесь хранить их в дереве? –

+0

Правильно, но почему бы ему даже следовать «125 | 30' в первую очередь? '123 | 27 * * будет * содержать '123 | 20', поэтому я не понимаю, почему он будет смотреть на '125 | 30' – rb612

+0

Это не так, но почему это мешает вам показывать этот узел на диаграмме? Я думаю, вы ошибаетесь в иллюстрации; стрелки указывают указатели, а не поток данных или поток программы. –

ответ

1

Сама диаграмма не отображает действия этого конкретного поиска, а скорее показывает локализованную часть дерева, поэтому я не буду слишком много читать в нем для конкретного запроса.

Вы абсолютно правы в поиске ключа 123-20, вам не нужно следовать по ссылке на второй листовой узел (либо по иерархической ссылке слева, либо по следующей ссылке сверху).

Однако (и это трудно сказать, не видя исходного материала), вполне вероятно, что эта диаграмма может быть использована и для чего-то другого.

Тот факт, что он показывает ссылки между последовательными листовыми узлами, означает, что было бы довольно просто использовать поиск индекса, чтобы найти конкретную запись, а затем последовательно обрабатывать их.

Под этим подразумевается запрос типа «дайте мне каждую запись с идентификатором сотрудника 123» или «дайте мне все записи с идентификатором сотрудника между 123 и 456» или «дайте мне все записи в идентификаторе employeeID/заказ".

Все эти запросы потребуют поиска определенной записи с использованием иерархического пути (хотя последний может иметь более быстрый путь к первой записи), а затем последовательный путь для последующих записей.

Кроме того, тот факт, что дополнительные идентификаторы 20 являются красными, означает, что это была бы идеальная возможность просвещать читателя о том, что индекс employee-subsidiary не всегда является лучшим для всех запросов. Другими словами, эффективный запрос «дайте мне все записи из дочернего элемента 20» будет лучше с другим индексом (который содержит просто вспомогательный идентификатор).

Это было бы мое лучшее предположение, было бы полезно посмотреть учебник, чтобы узнать, используется ли эта диаграмма для чего-то еще.


Конечно, мог быть, что человек, положив вместе учебник не может быть беспокоили создания нового графика так просто использовали один из другого вопроса, или более ранней итерации учебника :-) Я уже виноват в этом.

Смежные вопросы