БД дизайн использовать подтип или нет? - PullRequest
7 голосов
/ 31 октября 2009

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

  • note_id
  • note_type
  • note_type_id
  • note_content

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

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

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

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

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

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

Ответы [ 5 ]

11 голосов
/ 31 октября 2009

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

Например:

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

2 голосов
/ 31 октября 2009

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

books / book_notes / статьи / заметки к статье

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

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

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

В вашем контексте вы можете решить, что дополнительные издержки sql insert / select / update / delete для 3 таблиц заметок вместо одной только не стоят. В более долгосрочной перспективе, если вы изначально выбрали дизайн «1 таблица заметок», а затем решили, что он вам не нравится, разделить его на 3 - это не то же самое, что переписать войну и мир.

1 голос
/ 31 октября 2009

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

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

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

0 голосов
/ 04 ноября 2009

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

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

Примечание. Поля SuperType:

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

Поля общего подтипа:

  • Название
  • Автор
  • Дата

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

  • ISBN
  • Издатель
  • Цена
  • Etc

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

  • Webite
  • Права на распространение
  • Etc

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

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

0 голосов
/ 03 ноября 2009

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

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

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

...