DB设计是否使用子类型？

Question

我正在设计的数据库有三个主要表：BOOKS、ARTICLES、NOTES。

每一本书或一篇文章都可以有多个笔记，我最初的设计就是这样，这意味着书上的笔记和文章上的笔记都放在“笔记”表上。下面是NOTES表的列：

• note_id
• note_type
• note_type_id
• note_content

NOTE_TYPE可以是“book”，也可以是“book_id”；NOTE_TYPE_ID是book_id的FK，如果note_type是“book”，则为“”，如果note_type是“”，则为。

现在，我开始怀疑这是否是正确的(或最好的规范化)设计。另一种方法是使用5个表。

书籍/文章/笔记/ book_notes / article_notes

通过这种方式，我可以将书签和文章注释分开保存，列就像

‘'notes’{ note_id，note_content } 'book_notes‘{ book_id，note_id } 'article_notes’{ articel_id，note_id }

哪一个是正确的还是更好？

Answer 1

也许有一点不同的方法--超级类型/子类型通常是在每个子类型有非常具体的列时使用的，比如Person超级类型和病人和医生子类型。Person保存着所有人共有的所有数据，病人和医生为每个人保存非常具体的列。在本例中，您的book_notes和article_notes并没有太大的不同。

我宁愿考虑以图书和文章作为子类型的超级出版物。然后，您可以只有一个笔记表与FK出版。考虑到出版中的PK编号与图书(文章)的PK、FK相同，您可以使用出版物、图书或文章的注释进行连接。通过这种方式，您可以简单地添加另一个出版物，如“杂志”，添加一个新的子类表，而不更改有关Note的任何内容。

例如：

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
)

Book和Article表的主键也用作Publication的外键。

现在如果我们再加上另一个出版物，“杂志”：

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

我们不需要以任何方式修改Note --我们只添加了专门针对杂志的专栏。

​

​

Answer 2

从某种角度来看，从长远来看，使用它要好得多。

书籍/ book_notes /文章/article注释

作为数据库的设计原则。

当您考虑备份、数据操作和数据可移植性时，在它自己的表中拥有单个实体的属性就会开始得到回报。

从绝对意义上说，两者都不是真正的“更好”，而是取决于背景。人们习惯于把任何东西放在符合要求的橱柜里，学术数据库设计师们倾向于为每支牙刷创建一个橱柜。

在您的上下文中，您可能会决定不值得为3个便笺表(而不是仅一个)增加sql insert/select/update/delete的开销。从长远来看，如果你最初使用"1便笺表“的设计，然后决定你不喜欢它，那么把它分成3不像重写战争与和平。

Answer 3

NOTE_TYPE可以是“book”，也可以是“book_id”；NOTE_TYPE_ID是book_id的FK，如果 note_type是'book‘或是文章id (如果note_type是’‘)。

这种关系在逻辑数据模型上表示时称为弧。

如果你没有预见到任何音符的重复，那就好了。不仅仅是书之间，还有文章之间。