【问题标题】:DB tables design with a lot of attributes具有很多属性的数据库表设计
【发布时间】:2011-10-20 14:19:33
【问题描述】:

我想知道在这种情况下数据库设计应该是什么样子。

我想到的是每个实体的表格,例如:

Engine  
EngineDesign  
ElectricalSystem  
Drivetrain  
etc.

但在我看来,它有很多表。我的想法是好的还是过分了?

那传动系统呢?今天我们有 8 个齿轮,但只要制造商提供不同的东西,它就可以改变。

应该是这样的:
表(列)

DrivetrainId | 1st | 2nd | 3rd | etc.

或者

表格(行)

DrivetrainId | Gears
1            | 1st
2            | 2nd
3            | 3rd
etc.

【问题讨论】:

  • 我是否忽略了什么,或者这四个都是一样的?如果它们实际上并不相同,您如何识别引擎? (事实上​​,即使它们相同的,你如何识别引擎?通过引擎类型的值?)
  • 是我忽略了所有四辆车仅在装饰上有所不同。 :-) 我对关系 ENGINE - Type、Bore、Stroke 等感兴趣; DRIVETRAIN - 第 1、第 2、第 3、第 4 等,以及如何将这些属性放入表格中。如果可以将网页设计“镜像”到数据库,或者有更好的方法。图片只是结果的一个例子,值无关紧要。看看它,因为只有 1 列(1 辆车)。
  • 让我问你,一旦你有了这些信息,你想做什么?您会以小组的形式阅读它还是查询单个项目?如果您不打算查询它们而只是显示信息,则可以将某些内容放入注释字段中。
  • 我认为查询会非常精细。在产品或汽车的情况下,将根据排量、速度、油耗等或用户的选择进行比较。他/她想要一辆带有这种发动机和那种尺寸的红色汽车。

标签: database database-design data-structures


【解决方案1】:

您无法通过计算表来判断数据库设计的合理性。没有“太多表”范式或“没有足够表”范式之类的东西。也没有“列太多”范式或“列不够”范式之类的东西。

就目前而言今天,为每个传动齿轮比设置一列可能仍会让您达到 5NF。那是因为它没有多个列的值来自同一个域,这是一个问题。它有多个列,其值来自同一个域并且具有相同的含义,这是一个问题。

显然,8 档和 1 档有不同的含义。事实上,您可能会认为它们来自不同的领域。我的猜测是 0.67 不是 1 档的有效值,4.85 不是 8 档的有效值。

当这些存储在不同的列中时,

  • 很容易强制执行每行对 8 个传动齿轮比中的每一个都有一个值的约束,并且
  • 对每个齿轮比的有效值范围的限制非常简单。 (但您必须为以后只有 5 或 6 个齿轮的设计提供 NULL,这会引发标准化问题。)

当它们存储为行时,

  • 很难(也许不可能)强制每辆车对 8 个传动齿轮比中的每一个都有一个值,并且
  • 对每个齿轮比的有效值范围的约束更加复杂。 (特别是当您以后适应只有 5 或 6 个齿轮的设计时。)

【讨论】:

    【解决方案2】:

    我的第一反应是使用 Attributes 表和 Cars 表(我假设是汽车?)

    Attributes
    AttributeId | AttributeCategory | AttributeDesc
    
    Cars    
    CarId | AttributeId | AttributeValue
    

    编辑:请参阅下面的 cmets @HLGEM 解释为什么实体-属性-值表在此示例中不是一个好主意。

    【讨论】:

    • 是的,图片是关于汽车的,但我看到价格比较网站使用类似的东西,因为它们必须比较很多产品属性。
    • 以后查询的最糟糕的解决方案。
    • @HLGEM 你能解释一下为什么,或者给我一篇文章,这样我可以学得更好吗?我发现类似的解决方案在以后更灵活(添加或删除属性时)。
    • EAV 表的性能很差,只能作为最后的手段使用。它们很难查询,特别是如果您不知道自己拥有多少属性并成为每个人都在访问的争论点。例如,要查找所有十个属性,您必须连接到同一个表十次。如果你有 20 个属性,那么 20 次。他知道他想要什么领域,所以他不应该使用 EAV。如果您确实需要 EAV 信息,因为您无法知道自己拥有哪些属性,那么您应该使用 nosql 数据库而不是关系数据库。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-03-29
    • 2011-02-12
    • 2013-09-17
    • 2020-01-27
    • 2015-06-26
    • 2011-01-18
    相关资源
    最近更新 更多