0

Мне нравится модель вложенных наборов для хранения иерархических данных, и я хотел бы найти аналогичную модель для хранения зависимостей задач в приложении управления проектами.Схема базы данных для хранения филиалов/слияний в сети зависимостей

Выпуск 1: неустойчивые сложности рекурсивных запросов к базе данных/вызовы функций:

Прямо сейчас, у меня есть простой т: п таблица, которая хранит Task/Blocker пар, но цикл по данному неоптимизированной в лучшем случае , а в худшем - рекурсивный кошмар. Я хотел бы ограничить вызовы базы данных в узком цикле, и - с «нормальным» деревом - я использую вложенный набор, чтобы выполнить это.

Выпуск 2: множественное наследование, множественный Descendance

Причина я не могу использовать дерево является то, что этот набор содержит не только ветви, но и слияния. Некоторые задачи имеют несколько «родительских узлов» - если вы хотите - несколько задач, которые должны быть выполнены до того, как они начнутся. Это похоже на то, как я предполагаю, что SVN или Git должны работать для хранения информации о версиях.

Я хочу, чтобы выполнять запросы, как:

  • Получить все задачи, рекурсивно, в зависимости от конкретной задачи (сверху вниз обход)
  • Добавить все оценки времени для выполнения конкретной задачи, и все его зависимости (снизу вверх обход)
  • списка Ограничить потенциальные зависимости для задачи на логические опции (не может зависеть от себя, в цикле)

Возможные варианты до сих пор:

  • Байт пули и иметь дело со сложностью
  • Index все последовательности («маршруты», если хотите, чтобы закончить все задачи) - все еще не знаете, как хранить это
  • магазин как сверху вниз, вложенные наборы и восходящие вложенные наборы
  • Молитесь, что некоторые StackOverflow гуру знает больше, чем я на эту тему

что будет st way (и насколько вы уверены, что он будет работать)?

ответ

0

Я бы начал с задач и таблиц task_relationships.
Используйте таблицу task_relationships для нескольких родителей или детей.
отношение задачи имеет родительский и дочерний поля, оба являются идентификаторами в таблице задач.

+0

Именно здесь я и начал. Это насколько это возможно или есть следующий шаг для оптимизации запросов к иерархии? – landons

+0

следующим шагом может быть денормализация. У кого есть проблемы (производительность) и недостатки (согласованность, дублирование) –

+0

Итак, я мог бы поддерживать нормализацию отношений (за ваш ответ), но кэшировать некоторые подразумеваемые отношения (денормализованное представление) для повышения производительности при запросе данных. В этом есть смысл. Благодаря! – landons

Смежные вопросы