【发布时间】:2011-11-22 12:35:36
【问题描述】:
当一个想法被广泛引用时,它们在关系数据库中的多值属性有多好?
让我举个例子来说明我的意思。假设我有下表:
UserID Attribute1
User1 a,b,c
User2 x,y,z
User3 a,x,y
User4 c,b,z
[a,b,c,x,y,z are to be strings]
还有另一个用户User5,我必须根据他的Attribute1 是否与其他4 个用户中的任何一个匹配,向他提出一些关于其他用户的建议。
[在图形数据库中,任务可能会容易得多,因为我可以使用相同的关系从各个用户创建多个节点。]
现在,该表只是对实际数据库外观的微观抽象。表中的行数可能会达到数十万,如果不是数百万的话。此外,多个值实际上可能远远超过 3。除此之外,数据库可能处于高负载状态,在这种情况下,可能会出现一些问题。
那么,多值属性在这种情况下有用吗?或者有没有更好的方法来做同样的事情?我能想到的一种明显方法是将其存储为:
UserID Attribute1
User1 a
User1 b
User1 c
User2 x
User2 y
User2 z
User3 a
User3 x
User3 y
User4 c
User4 b
User4 z
在数据库中处理这种情况的任何更快的方法?或者是否有任何现代数据库的内置功能可供利用?
【问题讨论】:
-
我的直觉是,关系数据库的关系部分比字符串匹配部分优化得多:-) 数据库几乎总是工作得最好,并且在最标准化的形式下最容易优化,这将是后一种选择(所有属性分散到多行中)。
-
报告数据库通常在经过深思熟虑的非规范化后表现更好..
-
@mellamokb:“数据库几乎总是在最规范化的形式下工作得最好,并且最容易优化”——不正确:最高规范形式是 6NF 可能会导致“爆炸”表,需要许多连接来编写最简单的查询,并强制使用触发器或其他过程代码来强制执行表间约束,这两种方法都不利于优化。另请注意,如果 5NF 设计没有冗余,则可能没有什么实际理由将其采用 6NF 来消除某些重要的依赖关系。
标签: sql database database-design relational-database