Некоторое время я боролся с тем, как лучше всего обращаться с иерархиями в SQL. Разочарованный ограниченностью списков смежности и сложностью MPTT / вложенных наборов, я начал думать о простом хранении ключевых путей вместо простогоnode_key/node_key/... строка. Я решил собрать плюсы и минусы трех методов:

Количество вызовов, необходимых для создания / удаления / перемещения узла:Смежность = 1MPTT = 3Путь = 1 (Заменить путь к старому узлу новым путем ко всем узлам, содержащим этот путь)Количество звонков, необходимых для получения дерева:Смежность = [количество подуровней]MPTT = 1Путь = 1Количество вызовов, необходимых для получения пути к узлу / родословной:Смежность = [количество суперуровней]MPTT = 1Путь = 0Количество звонков, необходимое для получения количества подузлов:Смежность = [количество подуровней]MPTT = 0 (можно рассчитать по правым / левым значениям)Путь = 1Количество вызовов, необходимых для получения глубины узла:Смежность = [количество суперуровней]MPTT = 1Путь = 0Обязательные поля БД:Смежность = 1 (родитель)MPTT = 3 (родитель, справа, слева)Путь = 1 (путь)Заключение

Техника хранимого пути использует те же или меньшие вызовы, чем другие методики, в каждом случае использования, кроме одного. Благодаря такому анализу хранение путей становится явным победителем. Не говоря уже о том, что это намного проще в реализации, удобочитаемо и т. Д.

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

Кроме того, если вы считаете, что этот анализ неполон, пожалуйста, дайте мне знать.

ОБНОВИТЬ:

Вот, по крайней мере, две вещи, которые MPTT может сделать из коробки, чего не может сделать решение с сохраненным путем:

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