2 вопроса о дизайне базы данных. дерево иерархии

1.) У меня есть БД, где каждая запись представляет задачу. И из нескольких десятков, а то и сотен задач будет особая задача (которая является вехой)
Итак, в данном случае у меня очень мало записей, требующих дополнительного поля, чтобы отделить их от большинства.

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

Должен ли я создать еще одно поле только для хранения нескольких значений TRUE, в то время как остальные по умолчанию являются FALSE?

2.) Для каждой из этих задач у него есть переменное количество исполнителей (в зависимости от пользовательского ввода) (Кроме того, у каждого исполнителя есть несколько собственных исполнителей.) Таким образом, я, по сути, использую БД для описания ДЕРЕВА. структура. У меня сейчас так: у меня будет 5 копий одной и той же информации о задаче, если есть 5 исполнителей, и они займут 5 записей. Это путь, если у меня не будет более 10 000 записей (включая копии) в моей БД

Спасибо

Это должно прояснить это

  1. Task1 (это промежуточная задача)

    • performer1
      • sub-performer ID=21
      • идентификатор суб-исполнителя = 542
    • исполнитель2

  2. Task2 (это не промежуточная задача)

    • performer2
      • sub-performer ID=231

Subperformer и Performer — совершенно разные группы. Нет перекрытия вообще. Подисполнители — это группа, которая вносит свой вклад в исполнителя, чтобы исполнитель мог выполнить задачу, на которую он назначен.


mysql php database database-design hierarchy
person William Sham    schedule 31.05.2011    source источник
comment
Я не знаю, кто такие исполнители - они исполнители задачи или подзадачи?   -  person prodigitalson    schedule 01.06.2011
comment
является ли исполнитель подзадачей? персона ? что такое субчеловек?   -  person David Chan    schedule 01.06.2011
comment
Является ли исполнитель к задаче отношением n-1 или отношением n-m? Является ли исполнитель суб-исполнителю 1-n или n-m? Может ли исполнитель быть суб-исполнителем? Может ли исполнитель быть суб-исполнителем самого себя?   -  person Hyperboreus    schedule 01.06.2011

Ответы (3)


arrow_upward
1
arrow_downward

Я не уверен, что это то, что вы хотите:

tblTask ​​со столбцами taskID, isMilestone и всем необходимым.

tblAgent с колонками agentID и всем необходимым (это будут (суб)исполнители).

tblPerformance со столбцами fk_agentID, fk_task

tblSubperformance со столбцами fk_agentID_performer, fk_agentID_subperformer

Ссылка на внешние ключи fk_

fk_agent -> tblAgent.agentID
fk_task -> tblTask.taskID
fk_agentID_performer -> tblAgent.agentID
fk_agentID_subperformer -> tblAgent.agentID
person Hyperboreus    schedule 31.05.2011
comment
Я разместил EDIT со списком, который описывает структуру. В этой БД нет поля производительности. Просто задачи (уровень 1), исполнитель (уровень 2), вспомогательный исполнитель (уровень 3) - person William Sham; 01.06.2011
comment
Значит, вы не можете изменить структуру БД, чтобы сделать ее более эффективной? tblPerformance будет таблицей для реализации отношения m-n между исполнителями и задачами, а tblSubperformance — новой таблицей для отношения m-n между подчиненными исполнителями и исполнителями. - person Hyperboreus; 01.06.2011
comment
Теперь я понял, что вы говорите. Я думал, что производительность — это что-то новое. Я могу изменить свои таблицы. Спасибо за подробное объяснение. Чтобы уточнить, в таблице tblPerformance, если у меня есть Person A, Person B для задачи1. Тогда это будет выглядеть так: (-task1 fk_ID | Person A) ‹br› (-task1 fk_ID | Person B) - person William Sham; 01.06.2011
comment
Предположим, что задача 1 имеет идентификатор 42, агент А имеет идентификатор 2332, а агент Б имеет идентификатор 1234. Предположим, что агент А и агент Б являются исполнителями задачи 1. Тогда вам нужно будет ввести строки в tblPerformance, а именно (2332, 42) и (1234). , 42). Предположим, что агент C с идентификатором 5555 является подчиненным агента A, тогда в tblSubperformance у вас будет строка, говорящая (2332, 5555) - person Hyperboreus; 01.06.2011
comment
Благодарю вас! Это очень подробное объяснение. Теперь у меня есть работа по пересмотру моих сценариев. - person William Sham; 01.06.2011
comment
Рад помочь. Также, возможно, прочитайте литературу для начинающих о реляционных базах данных. - person Hyperboreus; 01.06.2011
comment
Один побочный вопрос. Так как некоторые из этих таблиц состоят только из внешних ключей. Должен ли я сделать первичный ключ из комбинации двух внешних ключей для каждой таблицы? - person William Sham; 01.06.2011
comment
Вы можете, но вам не нужно. Но, по крайней мере, вы должны объявить уникальное ограничение для двух столбцов, чтобы избежать того, что один агент выполняет одну и ту же задачу более одного раза. Также решение о том, где размещать индексы и какие индексы, зависит от того, какой запрос вы будете отправлять в БД в будущем. Например, если вам часто нужно знать, какие задачи назначены данному исполнителю, вы должны проиндексировать столбец fk_agentID в tblPerformance. - person Hyperboreus; 01.06.2011

arrow_upward
0
arrow_downward

1) да создайте логический флаг.

2) нет. если у вас есть повторяющиеся данные, у вас есть проблема. вам нужно нормализовать

person David Chan    schedule 31.05.2011
comment
Должны ли вы полностью нормализовать, чтобы избавиться от дублирования даже в случае иерархической ситуации. Не пострадает ли эффективность? - person William Sham; 01.06.2011

arrow_upward
0
arrow_downward

Вы действительно не используете реляционную природу баз данных. Хороший способ сделать это:

  • Иметь таблицу задач (с уникальными идентификаторами, без лишнего поля вех, без преформ)
  • Имейте таблицу вех с двумя столбцами: идентификатор задачи и специальное поле вехи - в этой таблице будут отображаться только вехи
  • Имейте таблицу с двумя столбцами: идентификатор задачи и исполнитель

  • Имейте таблицу с двумя столбцами: исполнитель и суб-исполнитель

  • Если у исполнителя может быть несколько полей, используйте идентификатор исполнителя в таблицах выше и создайте таблицу с идентификатором исполнителя и другими полями.

Re: комментарий

Я читал, что нормализация может снизить эффективность БД, поэтому я объединяю их все.

Где? Довольно странное утверждение.

Для таблицы, содержащей идентификатор задачи и исполнителя (3-й в вашем списке) Будет ли это так, если задаче 143 нужны сотрудники A, B, C. В БД (строка 1 | 143 | A) (строка 2 | 143 | B) (строка 3 | 143 | C) У вас еще нет резерва?

Повторение в третьей таблице не является проблемой избыточности, потому что вы не реплицируете никакой информации: информация в таблице относится к отношениям, а в трех строках есть три отношения.

Проблема избыточности возникает, когда у вас есть такая настройка, как ваша, если, скажем, задача 143 имеет дату завершения «31 мая 2011 года», тогда ваша таблица будет выглядеть так:

task_id  completion_date  performer
143      May 31, 2011     A
143      May 31, 2011     B
143      May 31, 2011     C

Теперь предположим, что я хочу изменить completion-date для задачи 143. В вашей настройке я должен изменить его во всех трех строках, и, что еще хуже, если кто-то сделает что-то не так, вы можете получить непоследовательную таблицу, например:

task_id  completion_date  performer
143      May 31, 2011     A
143      May 12, 2011     B
143      May 31, 2101     C

И теперь вы не знаете, какой правильный completion_date! Когда вы нормализуете, у вас есть только одна строка в одной таблице для изменения даты, и ваша база данных никогда не будет такой непоследовательной.

person trutheality    schedule 31.05.2011
comment
Я читал, что нормализация может снизить эффективность БД, поэтому я объединяю их все. Итак, правильная ли моя ситуация, чтобы полностью нормализоваться, и при этом эффективность не пострадает? Для таблицы, содержащей идентификатор задачи и исполнителя (3-й в вашем списке) Будет ли это так, если задаче 143 нужны сотрудники A, B, C. В БД (строка 1 | 143 | A) (строка 2 | 143 | B) (строка 3 | 143 | C) У вас еще нет резерва? - person William Sham; 01.06.2011
comment
Я прочитал это в книге Php, Mysql, Javascript О Рейли. Но я воспользуюсь вашим советом и разделю их. Большое спасибо! - person William Sham; 01.06.2011