БД дизайн использовать подтип или нет?

База данных, которую я разрабатываю, состоит из 3 основных таблиц: BOOKS, ARTICLES, NOTES,
Каждая книга или статья может иметь несколько заметок, мой оригинальный дизайн был таким же, что означает, что и заметки о книгах, и заметки о статьях попадают в таблицу "заметок". Вот столбцы для NOTES Таблица:

  • note_id
  • note_type
  • note_type_id
  • note_content

NOTE_TYPE может быть "книга" или "статья"; NOTE_TYPE_ID это FK для book_id, если note_type это "book" ИЛИ идентификатор статьи, если note_type это "article".

Теперь я начинаю задаваться вопросом, является ли это правильным (или лучше нормализованным) дизайном. Альтернативный подход заключается в использовании 5 таблиц

книги / статьи / заметки / book_notes / article_notes

Таким образом, я могу хранить примечания к книгам и примечания к статьям отдельно, столбцы

'notes' { note_id, note_content } 'book_notes' { book_id, note_id } 'article_notes' { articel_id, note_id }

Какой из них правильный или лучший?

Источник

5 ответов

Решение

Может быть, немного другой подход - супертип / подтип обычно используется, когда у вас есть очень специфические столбцы для каждого подтипа, как в супертипе Person с подтипами Patient и Doctor. Персонал хранит все данные, общие для людей, а Пациент и Доктор имеют очень конкретные столбцы для каждого из них. В этом примере ваш book_notes а также article_notes на самом деле не так уж и разные.
Я бы предпочел иметь публикацию супертипа с подтипами Book и Article. Тогда вы можете иметь только одну таблицу заметок с FK для публикации. Принимая во внимание, что номер PK в Publication совпадает с номером [PK,FK] Книги (Article), вы можете делать соединения с примечаниями по Publication, Book или Article. Таким образом, вы можете просто добавить другую публикацию, например, журнал, добавив новую таблицу подклассов и ничего не изменяя в отношении заметки.

Например:

TABLE Publication (ID (PK), Title, ...more columns common to any publication)
TABLE Book (ID (PK) = FK to Publication, ISBN, ... more columns specific to books only)
TABLE Article (ID (PK) = FK to Publication, ... more columns specific to articles only)
TABLE Note (ID, PublicationID FK to Publication, NoteText)

Первичный ключ для таблицы Book и Article также служит внешним ключом публикации.

Теперь, если мы добавим еще одну публикацию, журнал:

TABLE Magazine (ID (PK) = FK to Publication, ... more columns specific to magazines only)

Нам не нужно изменять Note каким-либо образом - мы добавили столбцы, относящиеся только к журналам.

pub_model_01

Источник

С определенной точки зрения, в долгосрочной перспективе гораздо лучше использовать

книги / book_notes / статьи / заметки к статье

как принцип дизайна для вашей базы данных.

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

Ни один из них не является "лучше" в абсолютном выражении, это зависит от контекста. Люди привыкли ставить в шкаф все, что подходит, академические дизайнеры баз данных, как правило, создают шкаф для каждой зубной щетки.

В вашем контексте вы можете решить, что дополнительные издержки SQL / вставки / выбора / обновления / удаления для таблиц 3 заметок вместо одной только не стоят. В более долгосрочной перспективе, если вы изначально выбрали дизайн "1 таблица заметок", а затем решили, что он вам не нравится, разделить его на 3 - это не то же самое, что переписать войну и мир.

Источник

NOTE_TYPE может быть "книга" или "статья"; NOTE_TYPE_ID это FK для book_id, если тип примечания - "книга" ИЛИ идентификатор статьи, если тип примечания - "статья".

Это отношение называется дугой, когда оно представлено в логической модели данных.

Хорошо, если вы не предвидите дублирования заметок. Не только между книгами, но и статьями.

Источник

Это зависит от того, что вы хотите сделать с подтипом. В ваших основных таблицах книги и статьи выглядят как подтипы "публикаций". Тем не менее, нет таблицы для "публикаций". Это потому, что вам не нужно искать публикации или вы не мыслили в терминах "реляционное моделирование обобщение-специализация"? Если вы посмотрите эту фразу в Интернете, вы увидите несколько хороших статей на эту тему.

Предполагая, что вам не нужна обобщенная таблица "публикаций", тогда вам, вероятно, также не нужна обобщенная таблица "заметок". Собираетесь ли вы искать заметки, где не имеет значения, к какой публикации относится заметка? Сколько времени пройдет, прежде чем вы захотите добавить третий или четвертый вид публикации?

Все это влияет на то, какой дизайн "концептуально лучше". Если вы хотите что-то лучше концептуально, тогда вы оптимизируете, понимаете ли вы это или нет. Возможно, вы оптимизируете с точки зрения качества, отличного от скорости или простоты.

Источник

Похоже, что вы должны сосредоточиться на заметках. Учитывая это утверждение, я бы создал структуру данных SuperType - SubType.

Заметки будут содержать все, что делает заметку уникальной (SuperType), и только те элементы из Книг и статей, которые являются общими для всех (SubType).

Обратите внимание на поля SuperType:

  • NoteID
  • NoteContent
  • NoteTypeId (1 = Книга 2= Статья)

Общие поля подтипов:

  • заглавие
  • автор
  • Дата

Записать уникальные поля: (NoteTypeId = 1)

  • ISBN
  • издатель
  • Цена
  • Так далее

Уникальные поля статьи: (NoteTypeId = 2)

  • Webite
  • Распределение прав
  • Так далее

Это позволяет людям искать или просматривать все заметки по содержанию, типу, названию, автору и дате. Затем для получения дополнительной информации вы переходите к деталям SubType.

Это также учитывает рост, так что вы можете легко добавлять другие подтипы по мере необходимости. Например, Blogs (NoteTypeId=3), FaceBookPages (NoteTypeId=4) и т. Д.

Источник
Другие вопросы по тегам