Hohol СерегаТак 12345678 - это 3 поля или одно? Если одно и числовое, то можно ли по 12 сделать внешний ключ? Я что-то сомневаюсь.
это одно поле. но его алгоритм формирования такой что можно по коду ТМЦ определить код группы и код подгруппы
Такой ключ - очень удачное решение.
Иерархию можно представлять двумя способами:
1. Ссылкой на "родителя"
2. Диапазонами (диапазон "ребенка" - является поддиапазоном "родителя").
Ваше решения совмещает достоинства обоих методов: номер "ребенка" указывает на "родителя" и сам может задавать диапазон для своих "детей".
В отличие от "чистого" первого способа можно выбирать "детей" одним запросом без рекурсии и сортировать по принадлежности своему "родителю".
Иногда это очень облегчает жизнь и разработчикам и пользователям.
Кстати, дополнительные таблицы (классы, подклассы, группы, подгруппы и т.д.) в общем случае не нужны и могут храниться в общей иерархии.

Hohol Тип-ТопТакой ключ - очень удачное решение.
Можно уточнить "Такой ключ" - это какой ?
Составной и хранимый в одном поле, по строго фиксированным правилам разбивки на группы, подгруппы, элементы.

Hohol Тип-ТопИерархию можно представлять двумя способами:
1. Ссылкой на "родителя"
2. Диапазонами (диапазон "ребенка" - является поддиапазоном "родителя").
А как в данном случае можно задать диапазон, где он должен быть задан ?
Здесь:
Hohol Тип-ТопВаше решения совмещает достоинства обоих методов: номер "ребенка" указывает на "родителя" и сам может задавать диапазон для своих "детей".
В отличие от "чистого" первого способа можно выбирать "детей" одним запросом без рекурсии и сортировать по принадлежности своему "родителю".
Иногда это очень облегчает жизнь и разработчикам и пользователям.
Кстати, дополнительные таблицы (классы, подклассы, группы, подгруппы и т.д.) в общем случае не нужны и могут храниться в общей иерархии.
Т.е. вы предлагаете вообще отказаться от справочников групп и подгрупп ? Тогда и самой иерархии не будет. Или предполагается что записи о группах и подгруппах должны быть в той же таблице что и записи о ТМЦ с указанием уровня и наличия подчиненных записей ?
Иерархия задается в единой таблице (разделение точками сделано для наглядности):

СерегаКогда я писАл на Клиппере такое было удобно и применялось повсеместно. Ты попробуй SQL-ем с такой "удачной" таблицей поработай. Если даже "разделение точками сделано для наглядности".
Во времена "Клиппера" (15-20 лет назад) я работал на Oracle 6 на SQL...

Серега Тип-ТопВо времена "Клиппера" (15-20 лет назад) я работал на Oracle 6 на SQL...
И что? Удобно SQL-ем пользоваться на такой структуре? Какие плюсы достигаются по сравнению с "обычной" структурой?
Об этом подробно писал Joe Celko. Можно найти его публикации в Интернет. Например, то в разделе Древовидные и иерархические структуры, хранение объектов были ссылки на его статьи.

Серега Тип-ТопОб этом подробно писал Joe Celko.
Читал. И что? Хранить информацию закодировано в одном поле лучше (удачнее) чем раскодировано в разных? Почему? Ведь для работы ее придется постоянно раскодировать. Зачем? Какой в этом великий смысл? Я не против кодов вместо безликого ИД в этом случае . Но зачем искусственно соединять эти коды в одно поле?
Затем, что становится легче получать "детские" и "родительские узлы", так как нет необходимости в рекурсии, которая в SQL не стандартизирована. Как следствие, такое решение является удобным и с точки зрения переноса структуры БД между СУБД.

Серега Тип-ТопЗатем, что становится легче получать "детские" и "родительские узлы", так как нет необходимости в рекурсии, которая в SQL не стандартизирована.
Может я не понял чего, но в чем облегчение то? Почему вычленение атрибута легче его простого чтения?
Речь идет не о легкости получения/вычленения атрибута, а о работе с БД на основе полученных значений. В случае, если используется схема со ссылкой на "родительский" узел, то для получения всех вложенных в данный узел "детских" узлов необходимо для каждого вложенного узла выполнить отдельный запрос. Если же иерархия задается диапазонами, то выполняется только один запрос.
Серега Тип-ТопКак следствие, такое решение является удобным и с точки зрения переноса структуры БД между СУБД.
Во первых непонятно за счет чего
За счет того, что схема не требует нестандартных решений, специфических для каждой СУБД (где-то есть возможность использовать запросы с рекурсией, где-то надо создавать селективные процедуры и т.д.).
Серегаво вторых - перенос на другую СУБД это все равно нетривиальная задача и "упрощение" (возможное, но не явное) на 3% роли, ИМХО, не играет. Да и не частая это задача, слава Аллаху.
Да, это не частая задача, но весьма трудоемкая. И возможность снизить эту трудоемкость за счет использования стандартных решений преуменьшать все же не стоит.
Но на всякий случай я подчеркну, что возможно применение любого из решений, как на диапазонах, так и на ссылках. Априори сказать, что какое-то из решений является лучшим всегда, - нельзя. Но если само устройство иерархического справочника соответствует конкретному решению, то надо иметь весьма серьезные аргументы, чтобы не следовать очевидному.