【问题标题】:The Name-Value-Pair Model For configuration-only data仅用于配置数据的名称-值-对模型
【发布时间】:2019-03-30 16:33:22
【问题描述】:

我读到数据库设计中的名称-值-对模型是一种反模式。本质上,您有一个包含两列的表。一列称为“名称”,另一列称为“值”。假设您正在管理不同区域的 AWS 配置。数据库结构如下:

name                                value
aws.new_york.access_key             jio4j54h
aws.new_york.site.user              john
aws.new_york.site.pass              eoiri4iiuh
aws.los_angeles.access_key          tret55464
aws.los_angeles.site.user           bob
aws.los_angeles.site.pass           rtry45yrt
aws.new_york.access_key             fgfhgf4fdg
aws.new_york.site.user              edward
aws.new_york.site.pass              45gfhgfhgf

唯一的用途是检索配置:

MyApp.config.get('aws.new_york.access_key')

另一种解决方案是使用连接。这将消除重复并允许参照完整性。但它变得很麻烦:

table_aws has_many table_states which has_many table_credentials 具有列 access_key、user、pass。这确实消除了重复,但想象一下嵌套连接数量增加的潜力。

鉴于我唯一的用例,名称-值-对模型模型仍然是反模式还是合适?

【问题讨论】:

  • 对于该用例,您可以使用单行表,每个参数有一列。
  • 如果你真的只有 3 个“属性”,那么,当然,一个 4 列的表非常好:“aws.new_york”在一列(或者可能是 2 个?),然后每个列access_keysite.usersite.pass。如果您希望偶尔添加更多属性,那么将它们设置为列会很麻烦。

标签: mysql database postgresql database-design database-agnostic


【解决方案1】:

您正在考虑的反模式可能是实体-属性-值。您正在描述一个简单的“哈希表”。如果这张表只有一百行,甚至一千行,都没有问题。

但是...您实际上是在描述 EAV,只是您把它弄得更乱了。

    aws.new_york.access_key 

实际上是 aws.new_york 作为“实体”和“access_key”作为“属性”。

通常,EAV 表应为 3 列,按此顺序排列为 PRIMARY KEY(entity, attribute)

如果您的目标只是“配置”的存储库,那么您不太可能会执行到达 EAV 崩溃的查询。

那么...让我们看看在通过判断之前您将如何处理数据集。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-03-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-09-16
    相关资源
    最近更新 更多