erpdms_ustinov,
т.е. это пока еще только идея, но в массы она еще не пошла?
стандартная идея...
так же, как и реализация

три таблицы максимум,
можно и в две уложиться

одно-, двух-, трех-уровневый...
какая ф ... разница?
стандартный иерархический справочник,
с неограниченным количеством иерархий,
для особых извращенцев гурманов можно и количество справочников не ограничивать ничем
если вы уж упомянули 1С - посмотрите, как это сделано там

s_ustinovChopстандартная идея...там есть некоторые нюансы. например - получить... средствами sql это напрямую не реализуется, а хранимыми процедурами...реализуется... :) без всяких дополнительных табличек и "нарушений нормализации" погуглите "деревья"... Например

Деревья в SQL Рекурсивные SQL запросы Простенький пример ( без упоминания умных терминов, множества, графы итд ): Построение дерева иерархии с помощью PHP / MySQL

на самом деле там действительно все стандартно и просто, один раз разберетесь, больше вопросов не будет... я использовал деревья " id-pid " (как и в 1С) все, что вы написали - стандартная задача выбора потомков по дереву, реализуется рекурсивным выбором, самый простое решение, как мне кажется почему вы противопоставляете " прямы средства SQL " и " хранимые процедуры "? по вашему хранимые процедуры не прямые? :)

s_ustinovChopбез всяких дополнительных табличек и "нарушений нормализации"
если для записи новых или модификации существующих записей необходимо использовать триггеры, которые будут модифицировать другие записи (перемещение узла по дереву) - данные не нормализованы (есть избыточность) - целостность данных лежит на пользователе. именно об этом я и писал.
мне примерно так и объяснял человек, как это описано в упоминаемых статьях. какая-то ахинея...
при перемещении узла по дереву в схеме [id-pid] никакие другие записи не модифицируются, только та, которая перемещается,
о контроле целостности голова болит у движка БД
скажу как на духу - никогда не использовала триггеры, для контроля целостности всегда хватало "штатных средств",
если же целостность завязана на бизнес-логике, то предпочитаю ее контроллить не в БД,
не люблю бизнес-логику в БД :)
а в MySQL и хранимые процедуры не использовал, хотя можно было :)
s_ustinovChopпочему вы противопоставляете "прямы средства SQL" и "хранимые процедуры"?переносимость между разными СУБД не очень. опять же, далеко не все СУБД поддерживают все нужные возможности (вроде у mysql была или и сейчас есть эта проблема). а обычный селект сработает в любой субд.а что же вы хотели?
у всех БД свои приколы
об "обычном селекте" вам тоже соврали - не перенесете вы "обычный селект" между разными СУБД :)

s_ustinovо схеме [id-pid]:
Очевидно, что при такой организации таблицы, с помощью одного SQL запроса можно извлечь только определенное число дочерних уровней.
...
Если высота дерева заранее неизвестна , то для извлечения всех узлов поддерева, для которого заданный узел является вершиной, придется создать рекурсивную процедуру .поддержки же рекурсии у некоторых субд нет до сих пор...а что же вы хотели?
деревья и без рекурсии? :)
я таких вариантов (нормальных) не знаю
s_ustinov1. для деревьев с большой глубиной часть запросов может отрабатываться слишком медленно, и проконтролировать заранее не получается на самом деле...
страшилки "будет отрабатываться медленно" - всего лишь страшилки
в том же php+MySQL реализуется и без поддержки рекурсии в СУБД
при размере БД в несколько тысяч записей время отработки вполне приемлимое
вот если у вас будут сотни тысяч записей в десятке-сотне таблиц... тогда таки да...
придется ставить какие-то ограничения - время жизни php-скрипта по умолчанию 30 сек.,
это можно изменить, если есть доступ к серверу, но
браузер пошлет ф попу через 50, если не дождется ответа :)
все загнется и безо всяких деревьев и рекурсий

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

5000 записей jQuery jqGrid с использованием пагинатора
успевает построить хоть в таблицу, хоть в дерево
1000 - успевает построить даже в ИЕ
больше - не проверял, не было нужды
s_ustinov2. есть проблемы, когда структура дерева сложная - например группа может входить в несколько других групп одновременно (холодильники - это и кухонная техника и крупная бытовая техника) и группа верхнего уровня будет включена в одну из своих подгрупп (бесконечный цикл) - например менеджер ошибся при переделке прайсаэти проблемы состоят исключительно в кривых руках прога, который это напишет :)
s_ustinovа если работать с деревьеми неограниченной глубины без рекурсивных процедур - надо добавлять дополнительные данные - появляется избыточность (денормализация). в упомянутой выше статье это описано.не надо ничего денормализировать, юзайте рекурсию,
при небольших объемах время обработки вас вполне устроит,
при больших - загнется и без деревьев и рекурсий
если есть желание еще ускорить процесс, избежать рекурсии и не нравится пагинатор - подгружайте каждую ветку дерева динамически по аяксу,
т.е. вначале выводите только один уровень дерева,
и лишь по дополнительному запросу - любой выбранный следующий один

и никаких рекурсий
s_ustinovChopоб "обычном селекте" вам тоже соврали - не перенесете вы "обычный селект" между разными СУБД :)опять же - можно пример "обычного селекта" (sql89), который не заработает на любой из распространенных современных рсубд?да и без примера - как только напишете LIMIT/TOP/FIRST/ROWS - фсе, кырдык, ваш запрос привязан к конкретной СУБД
а можно еще CAST вспомнить, можно еще повспоминать...
или это по вашему будет уже не обычный селект? :)

для " кроссбаззности " мужно узать DataBaseAdapter-ы различных php-фреймворков (если это php)
но на самом деле...
разве перед вами стоит задача написать софт, который будет работать с любой БД?

NZavaloffОднако, если в УС основной каталог 3-х уровневый, а на сайте 2-х уровневый, то при УС неплохо иметь промежуточный каталог (как модификация основного), который экспортируется в сайт (что я и сделал для случая 2 -> 2 с изменением структуры).самое главное в этом случае - иметь быстрообучаемую обизяну оператора, который будет получать зарплату за ввод и сверку "промежуточного каталога"