Древовидное хранение данных или «нормализованное» в АС?
Добрый день!
Товарищи, просим Вас помочь нам решить одну дилемму.
Разрабатываем/Имеем АС, в которой ведутся, ставятся задачи для сотрудников.
На данный момент имеем таблицу с задачами и отдельную таблицу с этапами данных задач.
Сейчас разработчики предлагают перейти к другой модели - этапы и задачи в одной таблице хранить (деревья организовать).
Моё скромное мнение (аналитика), что правильно оставить модель, которая сейчас существует, т.к. она позволяет быстро найти нужные этапы через обыкновенный JOIN по id. Позволяет сэкономить немного пространства.
Кто сталкивался с обоими подходами - какие плюсы, какие минусы?
Есть ли примеры, которые можно посмотреть?
1. Разместить разные данные в одной таблицы - это про денормализацию и никакого отношения к деревьям не имеет. Денормализация может создать очень много проблем, в том числе большое количество логических ошибок.
2. Если вы хотите хранить деревья с дугами произвольной длины, то использование одной таблицы - самый простой, но самый неэффективный способ работы с иерархиями.
3. В зависимости от типа СУБД могут быть встроенные возможности работы с иерархическими данными, они накладывают требования на формат хранения данных. Это самый правильный путь организации хранения иерархий.
Средний
