具有“开放式架构”的数据库 - 好或坏的想法?

时间:2010-05-18 02:59:24

标签: database database-design schema database-schema

Reddit的联合创始人介绍了他们在向数百万用户扩展时所遇到的问题。摘要可用here

让我感到惊讶的是第3点:

  

相反,他们保留了一个Thing Table和一个数据表。 Reddit中的所有内容都是一件事:用户,链接,评论,子评价,奖励等。事物保持共同属性,如上/下投票,类型和创建日期。 Data表有三列:thing id,key,value。每个属性都有一行。标题,网址,作者,垃圾邮件投票等都有一行。当他们添加新功能时,他们不再需要担心数据库了。他们不必为新事物添加新表或担心升级。

这对我来说似乎是一个可怕的想法,但它似乎已经为Reddit做出了贡献。不过,一般来说这是一个好主意吗?或者Reddit的特殊性是否正好为他们效力呢?

4 个答案:

答案 0 :(得分:16)

对于 entity-attribute-value ,这是一个称为EAV的数据模型。它有它的用途。一个主要的例子是自然稀疏的患者测试数据,因为可能会运行数十万个测试,但通常只有少数患者存在。一张包含数十万列的桌子很傻,但是带有EAV的桌子很有意义。

答案 1 :(得分:8)

大多数真正重要的网站最终在数据库方面使用某种非常简单的东西。这具有快速和可扩展的优点。它的缺点是,您要让数据库自动强制执行的所有关系(通过触发器等)需要在您的客户端代码中强制执行。保持一致性是一个痛苦的问题,至少在短时间内,您的数据几乎总是至少有一些机会不一致。

对于社交网站来说,这是值得的妥协。大多数情况下大部分时间的数据都是足够的(例如,如果您收到的某项物品的上票数量实际上是20毫秒时已经发送的话,谁真正关心的话),并且在缩放以支持数量时保持成本合理用户很重要。

答案 2 :(得分:7)

我注意到他们没有提到创建针对该数据的报告的难易程度。在狭窄的环境中使用时,EAV可能是有益的。作为大多数系统的核心部分,当您点击报告时,它将成为一场噩梦。 EAV的问题在于,大多数好处都是在项目开始时,大部分的痛苦都在分析和报告的后期,特别是由于严重缺乏数据完整性。 “不必担心外键”对我来说听起来像是孤儿行的噩梦。添加使用代理键的所有东西,你有一个纠结的泥沼,通常以完全重写结束

答案 3 :(得分:0)

不久前,我们就曾处理过类似的问题,我可以说一开始并不容易,而且很有趣,但是在您习惯了这一点之后,它就有了自己的利益,就像在开发您的另一个数据库一样表格,在某些方面这是一项过大的任务,但是当您通过这些级别时,它为您提供了许多功能,基本上一点之后,我们没有创建任何新表格,我们只是为所有表格创建了动态表格,甚至对于我们自己的编程任务。 至于性能,系统没有得到百万行的比较,但是对于日常使用,我从未发现任何差异。 我想分享一些问题。

  1. 我们没有删除任何行,我们只是隐藏它们并设置一个标志,而每晚(每周)的服务会清理物理行
  2. 孤立行,我们基本上不关心清理孩子,我们只是在父亲上设置了“ IsDeleted”,夜间服务会清理所有孤行或不再需要的行。

3。您应该使索引保持最新,但应尽可能不建立索引(再次夜间服务使索引保持最新)

  1. 我们提前准备了报告数据(AOT),这意味着我们在这里落后于实际数据:))

我们竭尽所能,不要跳入无数行,以根据用户需求计算一些值。如果我们准备好了就可以使用,否则就不能使用

最后,这种方法面临着许多独特的挑战,您应该找到一种解决方法,这是您在日常工作中从未遇到过的问题,但是毕竟,您将获得更多的灵活性,可以花很多钱。 / p>