【问题标题】:How to model relation to different type of objects如何建模与不同类型对象的关系
【发布时间】:2016-04-16 21:05:08
【问题描述】:

我正在开发一个用于创建和存储打印布局的软件。

  • 布局由一系列页面组成。
  • 每个页面都有一列或多列
  • 在每个内会有一个或多个元素
  • 列中的元素是有序的:元素的顺序是固定的
  • 元素可以是“文本”或“图像”类型(为简单起见,实际上还有更多类型)
  • 不同的元素有不同的属性。例如。图片有资源 url,文本有字体。请参阅帖子末尾的示例代码。

我的问题是关于对列和元素之间的关系进行建模。

想法 #1:一个表格包含所有元素

这真的很简单。将所有属性作为列添加到表中,并使用 N:N 关系对列和元素之间的关系进行建模。

关系可能是这样的

column_idelement_idorder
000000010000000010009
000000010000000020012
00000002000000006 0003

这对我来说似乎不是很吸引人,因为存储元素的表会被空条目污染,例如对于图像元素,所有 font 列都将为空。如果我考虑我拥有的所有不同的元素类型(大约 10 种),情况会变得更糟。

好处:SQL查询比较简单:

select * from
  relation_table R inner join elements E
  on R.element_id = E.id
where R.column_id = FIXED_COLUMN_ID

想法 #2:每种类型的元素一个表

对元素进行建模非常简单,只需为类元素的所有属性创建一列,然后添加特定元素类型的属性,例如图像。

但是如何对关系 column:element 建模呢?

我的第一种方法是尝试在关系中添加一列,指定将直接映射到相关表的元素类型:

column_idelement_idorderelement_type
00000001000000001 0012文本
000000010000000020003图片
000000020000000060005图片

这当然可行,但所有用于检索特定列元素的 sql 查询都会变得相当复杂。

问题

有没有一种方法可以结合 Idea #1 中的 sql 查询的简单性和 Idea #2 中更准确的数据库建模?

你如何解决这个问题?

P.S.:在其他情况下,我会切换到基于 nosql 的数据库,但这是不可能的 :-(

<?php
// Sample code of element structure
class element {
    protected $id;
    protected $order;
    // more properties, getters and setters...
}

class image extends element {
    protected $image;
    // more properties, getters and setters...
}

class text extends element {
    protected $font;
    // more properties, getters and setters...
}
?>

【问题讨论】:

    标签: php mysql oop database-design entity-attribute-value


    【解决方案1】:

    我认为你最好从一个元素表开始,然后添加连接表以获得各种元素类型所需的额外信息。

    在数据库设计中将数据建模为真实世界的实体通常是错误的,但最好退后一步,根据数据的内部依赖关系进行建模。这些通常是重合的(而且这样做的频率足以使现实世界的实体焦点看起来很有吸引力),但是当你遇到它们不一致的情况时,它会让你感到悲伤。

    在这里,您会遇到有关查询和排序的问题,这些问题在单个表中解决起来很简单,但在处理多个表时会让您头疼。

    【讨论】:

    • 好的,经过一番思考,我找到了类似的方法。一个元素表,用于引用列和存储所有元素类型的公共属性。然后为每个包含附加属性的元素类型添加一些额外的表。这将使我能够将 sql 查询的复杂性放入定义具体元素实例的类中。
    【解决方案2】:

    让我专注于混乱的部分:“不同的元素有不同的属性。例如,图像有资源 url,文本有字体。”正如您所说,这要求有许多可为空的列或许多不同的表。无论哪种情况,都是一团糟。

    解决方案...将这些“不同的元素”放入 JSON 集合中。将它放在一个列中,让应用程序对其进行解码并使用它们。

    使用该解决方案,结构仍在数据库中,但细节留给应用程序。似乎是一个公平的权衡。

    查看 EAV 的其他讨论。

    【讨论】:

      猜你喜欢
      • 2021-04-15
      • 2014-04-11
      • 2015-06-26
      • 2010-11-21
      • 2018-07-20
      • 2017-04-02
      • 1970-01-01
      • 2023-04-10
      • 1970-01-01
      相关资源
      最近更新 更多