DogenЕсть мысль создать классификатор регионов деятельности компании в виде дерева (хранимого в одной таблице - первичный ключ, ссылка на родителя, наименование и т.п.)
Обосновывается это тем, что с коммерческой точки зрения может понадобиться не просто завести таблицу стран, таблицу городов и т.д., а отразить не официальное административно-территориальное деление, а умозрительное - например, определенные города нужно поделить на районы, а некоторые страны вообще интересны укрупненно - Западная Европа, например.
Контрагент будет соотноситься только с одной записью из такого классификатора. Отчетность будет детализирована до заданного наперед уровня, или до уровня связи с контрагентами.


Мысль здравая и полезная. Именно сейчас и делаю такой справочник. Данные о регионах всасываю из КЛАДР, с некоторой предварительной обработкой. Детализацию лучше проводить до уровня населенного пункта (района города). Улицы лучше держать отдельно.

Dogen
Вопросы:
использовали ли кто-нибудь подобное на практике?
если использовали, то есть ли смысл вводить типы регионов (страна, область, район и т.п. - ведь реально такой классификатор и до квартир может быть детализирован).


До квартир не стоит, если захочешь посмотреть "ВСЁ" - начнутся тормоза (опробовано до уровня улиц).

Dogen
Для каких классификаторов вообще применялись деревья?
Например, для товаров я не вижу в этом смысла.
Кто-то здесь предлагал классифицировать так контрагентов - типа объединять их по-разному в холдинги и т.д., это мне тоже не нравится в общем-то (хотя если заводить таблицу контрагентов как таковых, а потом расшифровывать их с помощью таблиц физлиц, юрлиц и т.д., то структура становится поинтереснее и дерево контрагентов может быть оправданным решением).

Теоретиячески деревья можно применить к любому иерархическому классификатору, даже к плоским справочникам, объединив их в один. Все дело в том, как ты их объединишь и как в дальнейшем будешь проектировать базу данных. Работать с иерархическими классификаторами - задача не из легких, хотя выгоды, получаемые от их использования, значительные.
1. Возможность создания нового справочника (классификатора) без создания таблицы.
2. Использование ссылок на разные типы данных (стороннее предприятие, собственный цех, склад, сотрудник).
3. Используя ссылочные таблицы можно расположить объекты в зависимости от их принадлежности к той или иной иерархии.
И еще очень много вкусностей. Но, еще раз повторю, работать с иерархиями сложно, там своя специфика. Особенно при объединении всех справочников в один. Требуется тщательное проектирование зависимых структур базы данных.
И еще один момент. Очень хорошо работает с иерархиями Oracle.

Dogen
Я же говорю про заранее неизвестное количество уровней, и более того, про возможность наличия в дереве веток разной длины.

"Три китайца под окном пели оба об одном"
Иерархия такое представление и пдразумевает. Это просто как дерево
Dogen
Так что зависимые структуры проектировать легко :) Просто иметь в них ссылку на регион.

Блажен кто верует ... В примитивном случае использовать иерархический список легко. Сложнее управление этим списком, исключение дублей, контекстный поиск и еще несколько моментов.

DogenДык две связанных 1:n таблицы тоже иерархия.
Каких дублей? Какие вообще проблемы если это таблица из трех колонок???

Вы рассматриваете простейший случай использования иерархической структуры - таблицу из трех полей, хотя в иерархическую структуру можно уложить все справочники.
Дубли. При таком хранении неизбежно возникнут одинаковые наименования разных объектов. И даже не по вине оператора, а по причине нахождения этих объектов в разных ветвях дерева. Например населенный пнкт "Москва" встречается в справочнике регионов 4 раза Про населенный пункт "Сортировочный" и говорить не стоит. Еще момент: "Санкт-Петербург", "СПб", "Питер" и т.п. - это название одного и того же населенного пункта. Как контролировать? Про регистры вообще лучше промолчать. А эту проблему мне пришлось решить.
Dogen
1. Че подразумевается под дублем?
2. Че означает в данном контексте словосочетание "контекстный поиск"?
3. Какие все же моменты?

Контекстный поиск - поиск всего или части текста по условию.
Моментов еще много. При количестве записей > 300000 вывод всего дерева начинает подтормаживать несмотря на индексы и прочие оптимизаторы.
Dogen
Вот как исключить кольца в такой таблице, это было бы интереснее узнать. Хотя тоже фиг там проверять. Вообще тут много определится интерфейсом ввода.

С петлей, конечно, могут быть проблемы, но они разрешаемы проверкой. Хотя бы периодической или после ввода новых данных. А интерфейс ... Не столь сложно его сделать. Это уже зависит от программера.