Иерархия в БД

Доброго всем!

Есть задача построить БД с иерархической структурой. Нашел много информации про использование parent_id и использование дополнительной таблицы для хранения структуры. Во всех случаях используется id записи и на его основании строится структура вложенности ( если я, конечно, все правильно понял ). Но как быть если записи часто перезаписываются и соответственно часто меняются id. Бывает так, что из базы одновременно удаляется и вносится более 1000 записей в разных категориях. Тогда при каждой такой операции придется переназначать связку id - parent_id?

У меня вот какой вопрос: возможно ли вместо parent_id указывать имя родительского элемента?
Например:

id | element | parent |
--------------------------------
1 | elem 1 |
2 | elem 2 | elem 1 |
3 | elem 3 | elem 2 |
4 | elem 4 | elem 2 |
5 | elem 5 | elem 4 |

(Отредактировано автором: 09 Марта, 2016 - 11:47:15)

Поясните ещё раз, почему у вас часто изменяются id. Почему строки заменяются с изменением id, но вложенные множества остаются привязаны именно к этому новому элементу.

-----
PostgreSQL DBA

Потому что часто происходит удаление/добавление элементов и соответственно id удаленного элемента уже не существует.

Может я изначально думаю не в ту сторону?

У меня есть несколько категорий, которые редко изменяются, и множество элементов в этих категориях, которые постоянно удаляются/добавляются. Нужно их как-то связать.

Ещё раз: почему у вас часто меняются id родительских элементов так, что для их потомков требуется обновлять ссылку на родителя.


Эта постановка вопроса звучит так, как будто у вас вообще нет дерева, а только ссылка на категорию. Тогда почему у вас постоянно меняется id родителя? Категории же, как следует из этой же цитаты, достаточно стабильны.

-----
PostgreSQL DBA

Категории да, но структура самой таблицы похоже не верная.

Есть несколько уровней иерархии и некоторое количество сотрудников. Во вложении.

Таким образом получается, что поле с сотрудником одновременно является и категорией. При удалении или добавлении сотрудника, удаляется/добавляется категория. Как это правильно обработать?
Прикреплено изображение (Нажмите для увеличения)

(Отредактировано автором: 09 Марта, 2016 - 13:34:25)

Почему?

Опишите предметную область.

Сферическая схема подчинённости сотрудников: сотрудники отдельно, должности сотрудников отдельно (!), дерево должностной иерархии отдельно.

-----
PostgreSQL DBA

Потому что у каждого сотрудника есть подчиненные и один начальник. Допустим если я из примера удалю сотрудника с именем 6, то как быть с его подчиненными? И еще я хочу в пользовательском интерфейсе сделать возможность изменения иерархии. Например, изменить тип категории и назначить ей родительские элементы.


Получается несколько таблиц или все в одной можно сделать?

Всего один непосредственный начальник? Вы из какого-то параллельного мира


Повесить их в подчинённость кому-нибудь ещё.
Как вас спасёт имя родительского элемента вместо id? Всё равно обновлять эти записи с указанием нового руководителя.

Не знаю вашей предметной области, для моей организации можно было бы использовать какую-то такую схему:
сотрудники отдельно, здесь нет данных о должностях и начальниках.
должности отдельно. Здесь, если вообще нужны, данные о абстрактных должностях: совет директоров, начальник отдела, тимлид
Структура организации, описывающая как раз отношения между должностями. Например, ветвь для рядового разработчика: в корне совет учредителей, затем руководитель отдела ААА, тимлид, разработчик.
Другой разработчик в ветке совет учредителей, затем руководитель отдела БББ, тимлид, разработчик.
При этом, например, тимлид отдела ААА - учредитель (внимание, кольцо!), а руководители обоих отделов - один и тот же человек.

-----
PostgreSQL DBA

Плавно перешли от иерархии к связи таблиц

Значит, в данном случае нужно создать две таблицы: одна с сотрудниками, другая с должностями. В таблице с сотрудниками нужно будет хранить колонку с указанием id должности. Иерархию строить уже запросами. Так я понял?

Как-то так:
Прикреплено изображение (Нажмите для увеличения)

(Отредактировано автором: 10 Марта, 2016 - 11:58:21)