Nafесть табличка, типа есть группы в них группы или товары (как файлы-папки)Не самая подходящая аналогия, IMHO. Не стоит смешивать группы и товары в одной таблице. Этим, как минимум, усложняется проверка корректности данных. Например, группа может оказаться потомком товара, да и иерархичность товара вызывает сомнения.

Хранение иерархии "методом Селко" может показаться привлекательным чисто теоретически, но, как показала практика, он больше вызывает проблем, чем их решает. Разумеется, никто не может помешать проверить это утверждение самому. Какой метод выбрать взамен него, трудно сказать однозначно. Для некоторых задач вполне достаточно стандартной пары (ID, ParentID) и рекурсивных запросов.

Иерархия групп товаров - вещь, как минимум, очень неудобная, хотя бы по причине "жёсткости". В данном случае, IMHO, стоило бы применить "теговый" подход, когда к товару можно "прицепить" какие угодно теги, каждый из которых представляет собой ссылку на некий классификатор, в том числе и иерархический, если возникнет острая необходимость. Т.е., классический вариант связи M:N, реализованный через дополнительную таблицу, где с одной стороны товары, а с другой - теги(ссылки на классификаторы). Такой подход позволит строить "визуальные" иерархии, наиболее уместные в конкретной ситуации или для конкретного пользователя простым выбором последовательности тегов. Например, сначала по производителям, а потом по видам продукции, а можно наоборот, сначала по видам продукции, а потом по производителям.

P.S. Хотелось бы отметить, что на практике, IMHO, часто тяготеют к иерархическим структурам, где их наличие совершенно неоправданно. "Истинных" иерархий, подобно генеалогическому дереву, на практике не так уж и много. В таких случаях обычно подразумеваются, что все элементы этой иерархии однотипны.

Roman S. Golubinголословное утверждение.Роман, могу ответить в том же духе, твои примеры тоже являются голословным утверждением. Дабы избегать ненужного эпатажа и сосредоточиться на сути, предлагаю в дальнейшем исключить подобные формулировки. Мои утверждения основаны на моей практике, твои на твоей, давай исходить из этого.
Roman S. GolubinЗнаю как минимум два случая из личной практики, когда применение метода Селко избавило от необходимости приобретения дорогущего железа. При этом сложность добавления/удаления/изменения данных для процедур, которые с этим деревом работали, ни как не изменилась.Разумеется, если использовать метод вложенных множеств(Селко) в качестве альтернативы дилетантским решениям, то не исключаю, что он может выиграть по некоторым пунктам. Но от его родового проклятия, пересчёта и модификации LR-значений, в среднем затрагивающих до половины узлов дерева, увы, не избавиться.
Если использовать большую разреженность значений, чтобы снизить объем модификаций, то мы теряем некоторые преимущества, которые даёт непрерывность LR-последовательности, при этом дополнительная проверка на предмет нахождения внутри псевдофиксированных границ остаётся.
Даже для простейшего поиска всех потомков узла необходимо использовать слияние, для получения по идентификатору узла его LR-значений, чтобы выбрать потомков, чьи LR-значения находятся внутри LR-границ предка. Причем сами LR-значения мы не можем использовать в качестве ключа в связи с их потенциальной изменчивостью.
Поиск всех предков листа приводит к сканированию всех узлов дерева, что с учётом потенциальной перестройки дерева при модификации может породить немало проблем. То же самое произойдёт при попытке вычислить уровень листа.
Слишком часто используется between, что мешает использованию merge- и hash-алгоритмов при различных выборках. Да и с индексом есть проблемы, так как у нас для каждого узла есть 2 совершенно независимых друг от друга значения. В результате, польза от индекса (L,R) невелика, а использование 2 отдельных индексов по L и R сервером запросто игнорируется с точки зрения IO. Дешевле сделать seek+scan по какому-либо одному из них.
Roman S. GolubinВместо корявых и медленных циклов / курсоров / CTE для выборки данных из деревянной структуры, были написаны однопроходные запросы и построены индексы. При этом, скорость работы увеличилась на несколько порядков, а нагрузка на железо упала в несколько раз.Я тоже видел много ужасных реализаций, но это говорит лишь об уровне их авторов. Тем более, что ты упомянул создание индексов, исключение курсоров. Так зачем же противопоставлять заведомо плохую реализацию работы с деревом и метод вложенных множеств, который при реализации тем же программистом мог бы точно так же, если не хуже, похоронить сервер ?
Цикла в случае стандартных (ID, ParentID) может и не избежать, но без курсоров можно запросто обойтись, этот способ был предложен в BOL еще к MS SQL версии 4.21. Почти уверен, что нормальная реализация такого подхода не сильно бы уступала методу вложенных множеств.
В случае неглубоких деревьев(2-3 уровня, что нередко бывает на практике) не думаю, что CTE принципиально проигрывает методу вложенных множеств при "правильных" индексах. Впрочем, это моё голословное, умозрительное, утверждение, сам экспериментов не ставил. Если есть обратная статистика, а ещё лучше, воспроизводимый пример, то был бы рад ознакомиться.

IMO, метод вложенных множеств может использоватся в случае не очень больших и редкоизменяющихся деревьев. Лично я исключил его из своей практики, предпочитаю развёртывание иерархии в дополнительных полях и/или таблицах.