Дизайнът на Nested Sets определено е труден, когато трябва да правите чести актуализации на дървото. В крайна сметка трябва да преномерирате големи части от дървото.
Едно предложение за смекчаване на това е да се използват числа с плаваща запетая вместо цели числа. Ако вмъкнете нов възел в дървото, е сравнително лесно да намерите някои FLOAT числа между вложените номера на набора на родителя на новия възел. В крайна сметка може да стигнете до границите на точността на число с плаваща запетая, но тъй като дървото ви не е много дълбоко, това няма да се случи за дълго време.
Друга техника, за която съм писал, наричам Closure Table . Този метод за съхранение на йерархии прави много по-лесно вмъкването/актуализирането/изтриването на възли в голямо дърво, без да е необходимо да актуализирате голяма част от вашето дърво. И все още можете да заявите цялото дърво или всяко поддърво в една нерекурсивна SQL заявка.
За да прочетете повече за таблицата за затваряне, вижте:
- Кой е най-ефективният/елегантен начин за анализиране на плоска таблица в дърво?
- Модели за йерархични данни с SQL и PHP
- Преместване на поддървета в йерархии на таблици за затваряне
- SQL Antipatterns:Избягване на клопките на програмирането на бази данни
Относно вашия коментар:
Списъкът на съседство е прост, има минимум излишък и поддържа FK връзки, което вложените набори не. Списъкът на съседство поддържа заявки за цяло дърво с произволна дълбочина, ако използвате рекурсивни заявки . Но MySQL не поддържа рекурсивни заявки.
Ако трябва да заявите само непосредствени връзки родител-дете (т.е. едно ниво на дълбочина) или по друг начин да заявите само дървета с фиксирана дълбочина, тогава списъкът на съседство е добре.
