微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

php – 适当的数据结构,以保持一对多的关系

我想在数据库中表示文档.有几种不同类型的文件.所有文件都有一些共同点,但并非所有文件都相同.

例如,假设我有一个基本的文档表…

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 举报,一经查实,本站将立刻删除。

相关推荐