Мое предупреждение о вложенных наборах для иерархических наборов данных произвольной глубины: хорошо или плохо? - PullRequest
Новая
       21

Мое предупреждение о вложенных наборах для иерархических наборов данных произвольной глубины: хорошо или плохо?

7 голосов
/ 15 ноября 2011

При воссоздании моей CMS я хотел использовать альтернативу традиционному родительскому / дочернему подходу для управления иерархией карты сайта / страницы.Я вспомнил, что видел модель с вложенным множеством некоторое время назад, но не мог вспомнить, как она называлась.Итак, я наткнулся на похожий подход, который я хочу оценить и сравнить свойства, убедившись, что я не столкнусь с глупыми ограничениями позже, потому что я не пошел с тем, что уже проверено временем.Поэтому, пожалуйста, сообщите, если А) это уже было изобретено (как это называется ?!), Б) есть фундаментальные недостатки в свойствах, или С) это хороший подход (пожалуйста, дайте хорошее обоснование!).

Рассмотрим этот список:

  • Дом
    • О нас
    • Свяжитесь с нами
    • Продукты
      • Одежда
      • Книги
      • Электроника
    • База знаний
    • Прочие вещи

Под вложенным набором моделиЯ полагаю, что вы сохраняете левый / правый дескрипторы для каждого узла с обходом в глубину: 

Home                  1-18
    About Us          2-3
    Contact Us        4-5
    Products          6-13
        Clothing      7-8
        Books         9-10
        Electronics  11-12
    Knowledge Base   14-15
    Other stuff      16-17

И вот мой «неправильный путь», который мне начинает нравиться лучше: 

Home                  1-9
    About Us          2-2
    Contact Us        3-3
    Products          4-7
        Clothing      5-5
        Books         6-6
        Electronics   7-7
    Knowledge Base    8-8
    Other stuff       9-9

Вместо левой / правой пары я храню ID и LAST_CONTAINED_ID.Я обнаружил, что многие свойства одинаковы (или очень похожи):

  • Корневой узел имеет ID = 1
  • Для «листьев» оба свойства равны, в то время как светви не являются
  • Общее количество «подузлов» для любого данного узла равно LAST_CONTAINED_ID - ID
  • Все содержащиеся в нем узлы имеют идентификатор> идентификатор контейнера, но <= LAST_CONTAINED_ID контейнера </li>
  • Узлы-предки имеют идентификатор <дочерний идентификатор, но также и LAST_CONTAINED_ID> = идентификатор дочернего элемента
  • Глубина равна сумме узлов-предков

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

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

Я приветствую ваши мысли.

1 Ответ

4 голосов
/ 16 ноября 2011

Единственное преимущество, которое он дает, - это функция «без пропусков», но для достижения этой цели вам пришлось изменить логику, примененную к правильным значениям. В исходной модели вы получаете детей «Продуктов», видя все эти значения 6 <.. <13, но в вашей модели вы получаете этих детей, видя значения 4 <.. <= 7. Необходимость обращаться с значения, отличные от левых, делают его немного менее элегантным. <br> Еще один незначительный недостаток заключается в том, что в оригинале переход с 12 на 14 подчеркивает, что вы изменили уровень, тогда как в вашей модели вы не получите таких визуальных сигналов.
Так что, если вы счастливы использовать (<, <=) вместо (<, <), то это работает. (Так как это выглядит эквивалентно, я не могу сказать «хорошо» или «плохо», но вы уже выделили опасность реализации пути, по которому пройдено меньше.) </p>

...