我想在数据库中表示文档.有几种不同类型的文件.所有文件都有一些共同点,但并非所有文件都相同.
TABLE docs (
ID
title
content
)
现在让我们说我有一个可以属于用户的文档子集,并且可以有与之关联的其他信息.我可以做以下……
TABLE docs (
ID
userID -> users(ID)
title
content
additionalInfo
)
…但是这会导致表中有很多空值,因为只有一些文档属于用户,而不是全部.所以相反,我创建了第二个表“ownedDocs”来扩展“docs”:
TABLE ownedDocs (
docID -> docs(ID)
userID -> users(ID)
additionalInfo
)
我想知道:这是正确的方法吗? (我很担心,因为虽然一切都在一个表中,但我在文档和用户之间有一对多的关系.但是,通过创建一个新的表ownedDocs,数据结构看起来像我在docs之间有多对多的关系和用户 – 永远不会发生.)
在此先感谢您的帮助
解决方法:
“by creating a new table ownedDocs,
the datastructure looks like I have a
many-to-many relationship between docs
and users – which will never occur.)”
如果将OwnedDocs.DocId设为主键,则很明显1:N关系是不可能的.
零或一对一关系的建模是棘手的.如果我们只有一个子类型,那么具有NULL列的单个表是一种合理的方法.但是,最好确保仅在适当时填充子类型属性.在给定的示例中,这意味着检查约束以强制执行此规则:
check (userID is not null or AdditionalInfo is null)
或者甚至可能是这条规则:
check ( (userID is not null and AdditionalInfo is not null)
or (userID is null and AdditionalInfo is null) )
属性之间的关系不会显示在ERD中(除非您使用命名约定).当然,在第二种情况下,所拥有文件的AdditionalInfo的强制性质不会很明显.
一旦我们有几个这样的子类型,单独表格的情况变得引人注目,特别是如果子类型构成弧形,例如文档可以是FinancialDocument,也可以是MedicalDocument或PersonnelDocument,但不能超过一个类别.我曾经使用一个包含大量空列,视图和检查约束的表来实现这样的模型.那太差了.子类型表肯定是要走的路.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。