【问题标题】:Is it better to use fewer tables with more columns or vice versa?使用更少的表和更多的列会更好,反之亦然?
【发布时间】:2014-07-28 03:40:57
【问题描述】:

我正在尝试找出如何确定构建数据库的最佳平衡点。我希望能够存储来自不同人提交的几种不同表单的信息,有时是多次(例如每年更新一次)。我被困在为每个表单使用不同的表,或者表单和元素定义和元素值表的组合之间。

示例A:有三种不同信息的表格,所以有四个表格,[FormA]、[FormB]和[FormC],每个表格都有与各自表格关联的数据,全部FKed到[Customers ].

示例 B:相同的三个表格,但这次有五个不同的表格。 [FormDescriptions] 定义表单名称、类型等,并具有三个条目,每个表单一个。 [Forms] 对 [Customers] 和 [FormDescriptions] 的 FK,并将它们与提交日期结合使用以区分各个提交。 [FormElements] 定义了三个表单中的所有元素,在 FormDescriptions 上有一个 FK 和一个唯一的 elementID。 [ElementValues] 对 [FormElements] 和 [Forms] 进行 FK,并将所选元素的值存储在所选表单上。

我的问题是,这些方法中的一种在本质上是否比另一种更好,如果不是,在哪些情况下各自优于另一种?非常感谢您想要包含的原因或原因。

【问题讨论】:

    标签: sql database database-design relational-database database-schema


    【解决方案1】:

    “我的问题是,这些方法中的一种在本质上是否比另一种更好,如果不是,在哪些情况下各自比另一种更好?感谢您想要包含的为什么或为什么不包含。”

    您的选项二是(您的个性化变体)EAV 反模式。如果您使用它,并且您希望(现在或以后)系统对数据执行任何“智能”操作,那么您会发现自己遇到了严重的麻烦。像“严格的数据验证以捕获数据输入错误”这样基本的东西已经被称为“智能”。因此,仅当您可以合理地预期系统将用于仅用于存储数据并且不太可能有请求时才使用它开始以“智能方式”处理/操作数据。

    如果您曾经遇到过使用 EAV 数据库开始做“智能”事情的请求,您会发现无论您认为通过使用超级通用信息模型获得的开发时间如何,您都将失去几个数量级花费更多时间编写所有所需的“智能”事物,即在代码中恢复您拒绝反映在数据库中的数据结构。

    谷歌搜索“EAV 反模式”(尝试查找 Bill Karwin 的书)应该会为您提供足够多的信息来说明为什么不这样做。

    【讨论】:

      【解决方案2】:

      这里要考虑两个因素

      1. 性能
      2. 灵活性

      如果您的系统需要您以后经常添加更多表单。方法 2 更好。您不必添加其他表或列。您的表单是数据驱动的。它不会增加生成表单和保存为键值对的开销。

      另一方面,如果您的系统不需要对表单进行很多更改,则第一种方法可以工作。

      还要考虑表单提交后的数据使用情况。你要对这些数据进行分析和报告吗?这些报告是否特定于表格?这将有利于方法 1。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2013-11-07
        • 2018-11-30
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多