Дизайн DB для использования подтипа или нет?
Я столкнулся с той же ошибкой и застрял в ней на много дней. Наконец-то решили проблему. Я работал над проектом, в который было добавлено много библиотек классов. Я добавил ссылку на эти библиотеки в свой основной проект и по ошибке добавил ссылку на тот же проект на себя. Поэтому, когда я удалил ссылку на себя, это сработало.
5 ответов
Maybe a bit different approach -- supertype/subtype is usually used when you have very specific columns for each subtype, like in Person supertype with Patient and Doctor subtypes. Person holds all data common to people and Patient and Doctor hold very specific columns for each one. In this example your book_notes and article_notes are not really that different.
I would rather consider having a supertype Publication with Book and Article as subtypes. Then you can have just one Note table with FK to Publication. Considering that a PK number in Publication is the same number as the [PK,FK] of Book (Article) you can do joins with notes on Publication, Book or Article. This way you can simply add another publication, like Magazine by adding a new sub-classed table and not changing anything regarding Note.
For example:
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 (PK)
, PublicationID = FK to Publication
, NoteText
)
Primary key for Book and Article tables also serves as a foreign key to the Publication.
Now if we add another publication, Magazine:
TABLE Magazine (
ID (PK) = FK to Publication
, -- more columns specific to magazines only
)
We do not have to modify Note in any way -- and we have added columns specific to magazines only.
С определенной точки зрения, в долгосрочной перспективе гораздо лучше использовать
books / book_notes / article / article notes
в качестве принципа построения вашей базы данных.
Когда вы рассматриваете резервное копирование, манипулирование данными и переносимость данных с течением времени, наличие атрибутов одного объекта в его собственной таблице начинает окупаться.
Ни то, ни другое не является «лучше» в абсолютном выражении, это зависит от контекста. Люди привыкли класть в шкаф все, что подходит, разработчики академических баз данных, как правило, создают шкаф для каждой зубной щетки.
В вашем контексте вы можете решить, что дополнительные накладные расходы на sql insert / select / update / delete для 3 таблиц заметок вместо одного только не стоит. В более долгосрочной перспективе, если вы сначала выберете дизайн «1 таблица заметок», а затем решите, что он вам не нравится,
NOTE_TYPEможет быть «книга» или «статья»;NOTE_TYPE_ID- это FK для book_id ЕСЛИ тип примечания - «книга» ИЛИ идентификатор статьи, если тип примечания - «статья».
Это отношение является называется дугой при представлении в логической модели данных.
Это нормально, если вы не предвидите дублирования заметок. Не только между книгами, но и статьями.
Похоже, вы должны сосредоточить внимание на Notes . Учитывая этот оператор, я бы создал структуру данных SuperType - SubType .
Notes будет содержать все, что делает заметку уникальной (SuperType) и только те элементы из Книг и статей , которые являются общими для всех (подтип).
Поля супертипа примечания:
- NoteId
- NoteContent
- NoteTypeId (1 = Книга 2 = Статья)
Общие поля подтипа:
- Заголовок
- Автор
- Дата
Уникальные поля книги: (NoteTypeId = 1)
- ISBN
- Издатель
- Цена
- И т. Д.
Уникальные поля статьи: (NoteTypeId = 2)
- Веб-сайт
- Права на распространение
- И т. Д.
Это позволяет людям искать или просматривать все Заметки по содержанию, типу, названию, автору и дате. Затем, чтобы получить дополнительную информацию, перейдите к деталям Подтип .
Это также обеспечивает возможность роста, поэтому вы можете легко добавлять другие подтипы по мере необходимости. Например, блоги (NoteTypeId = 3), FaceBookPages (NoteTypeId = 4) и т. Д.
Это зависит от того, что вы хотите делать с подтипом. В ваших основных таблицах книги и статьи кажутся подтипами «публикаций». Однако таблицы для «публикаций» нет. Это потому, что вам не нужно искать публикации, или потому, что вы не думали о «реляционном моделировании обобщения-специализации»? Если вы поищете эту фразу в Интернете, вы найдете несколько хороших статей по этой теме.
Если вам не нужна обобщенная таблица «публикаций», то вам, вероятно, не нужны общие «заметки». стол тоже. Собираетесь ли вы искать заметки, где не имеет значения, к какому типу публикации относится эта заметка? Сколько времени пройдет, прежде чем вы захотите добавить публикации третьего или четвертого типа?
Все это влияет на то, какой дизайн «концептуально лучше». Если вы хотите чего-то концептуально лучшего, вы оптимизируете, понимаете вы это или нет. Возможно, вы оптимизируете с точки зрения качества, отличного от скорости или простоты.
тогда вы оптимизируете, понимаете вы это или нет. Возможно, вы оптимизируете с точки зрения качества, отличного от скорости или простоты. тогда вы оптимизируете, понимаете вы это или нет. Возможно, вы оптимизируете с точки зрения качества, отличного от скорости или простоты.