Как структурировать схему реляционной базы данных, если один и тот же объект должен использоваться для двух разных целей? - PullRequest
Новая
       12

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

0 голосов
/ 07 сентября 2018

Я создаю схему реляционной БД для системы тикетов. Система тикетов будет иметь два разных типа задач (тикетов), которые, я бы сказал, я должен хранить в отдельных таблицах базы данных. Однако оба типа задач будут иметь заметки, а заметки будут иметь одинаковые свойства, независимо от типа задачи, к которой они принадлежат.

Отношения между Task1 и NoteForTask1, а также Task2 и NoteForTask2 являются одно-ко-многим (одна задача может иметь 0 - n заметок).

Моя идея о том, как должны выглядеть таблицы Task1 и Task2 (помните, что Task1 и Task2 имеют совершенно разные свойства): 

Task1
  Task1ID <PK> 
  Task1Property1
  Task1Property2
  etc...

Task2
  Task2ID <PK>
  Task2Property1
  Task2Property2
  etc...

Поскольку заметки для обеих задач имеют одинаковые свойства, таблицы NoteForTask1 и NoteForTask2 должны выглядеть следующим образом: 

NoteForTask1
  NoteID <PK>
  Task1ID <FK>
  NoteText

NoteForTask2
  NoteID <PK>
  Task2ID <FK>
  NoteText

Поскольку Note1 и Note2 имеют абсолютно одинаковые свойства, я думаю, было бы неплохо сохранить их в одной таблице базы данных. Но в этом случае внешние ключи для Task1 и Task2 будут перекрываться, поскольку Task1ID и Task2ID имеют свою собственную последовательность, поэтому из самого внешнего ключа TaskNID невозможно определить, является ли это идентификатором Task1ID или Task2ID.

Как структурировать схему БД так, чтобы Задача1 и Задача2 содержались в двух отдельных таблицах, но чтобы в одной таблице были заметки? Или это совершенно неправильный подход, и я должен хранить два разных типа заметок в двух отдельных таблицах?

...