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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了php – 适当的数据结构,以保持一对多的关系，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1665字，纯文字阅读大概需要3分钟。

内容图文

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

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

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,但不能超过一个类别.我曾经使用一个包含大量空列,视图和检查约束的表来实现这样的模型.那太差了.子类型表肯定是要走的路.

内容总结

以上是互联网集市为您收集整理的php – 适当的数据结构,以保持一对多的关系全部内容，希望文章能够帮你解决php – 适当的数据结构,以保持一对多的关系所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端