重叠对象/数据实体类型的最佳实践

Question

偶尔我会遇到以下所有条件对两个高度相似但不完全相同的实体或对象都为真的情况。这使我很难决定如何对它们进行建模，无论是在数据库端还是在对象建模方面。我会试着详细说明这个问题和我的问题，因为我发现它是一个非常难以定义的建模问题。我正在尝试使用这些实体进行数据和对象建模，因此我将稍微松散地使用这两个学科的术语。

1）两个实体共享许多相同的属性，但有一些没有在另一个中找到的独特属性。

2）一个不是另一个的超类型或子类型。

3）重叠不是由于对象继承。

4）对象用于不同目的在同一个域中，但通常在任何工作流中都非常接近。这经常导致那些具有中等领域知识的人混淆实体。另一方面，这种精细的分离导致相关对象的方法之间的差异比它们的属性更大。

5）在某些情况下，可能在数据库端创建桥表以表示实体之间的M2M关系。尽管如此，它们拥有如此多的属性（或数据库方面的列），因此将它们存储在同一个表中可能有意义。

我碰到的一些案例包括： 1）“产品vs.项目混淆” - 尤其是在产品和项目共享许多相同属性的软件营销中。通常情况下，一个产品将有多个与之相关的项目，但同时也可以想象一个项目可用于多种产品。

2）软件开发中功能和组件之间的细微差别。一个功能是以开发人员为中心的一种手段，从客户的角度提供一个好处，而一个组件是开发人员实现功能的一种手段。这是一个非常微妙的区别，尽管如此。有关进一步的讨论，请参阅Rod Maupin的文章http://www.installationdeveloper.com/347/features-and-components-101/

3）模板与很多不同问题域中的类型。例如，当通过TypeID列识别吉他的类型时，它引用的TypeTable可能会有与色彩，字符串大小，体形等相对应的列。另一方面，模板是您要制作吉他的东西from，因此它可能与Type有不同的方法，可能链接到“应用模板”或“从模板生成项目”菜单命令。尽管如此，它将具有许多与Type相同的列或属性，例如颜色，形状，字符串大小等。这种区别在许多问题域中引发数千种不同对象类型和模板，而不仅仅是这个狭窄的示例。使事情进一步复杂化，在某些情况下，将多个模板与特定类型相关联和/或反之亦然可能会有所帮助。

我还没有遇到这种经常重叠实体的问题，但是当它发生时，它就成为一个真正的瓶颈，并导致重构​​数据和对象模型的很多浪费时间。我已经阅读了关于这两个主题的书籍，并且对数据/对象建模网页进行了大量关于该问题的搜索，但尚未见到它的讨论。我在StackOverflow上可以找到的唯一匹配是“重叠”和“数据模型”，用于区分一个表或实体中的相似列，而不是跨表或实体。我的问题是：

1）此问题是否有正式名称？

2）是否有贸易在建模过程的开始，以确定这种重叠的实体，而不是更远的路线，当后知后觉，使重构问题的一个简单的快捷方式或把戏？

3）如何处理这些重叠的实体？我认为就面向对象而言，它们应该有单独的对象，因为它们的方法往往是不同的。从另一个继承一个将是尴尬的。更难的问题是在数据库端使用单独的表是否合理。将它们组合起来可能需要一系列复杂的视图，当它们不共有的属性/列保留为空时，会浪费存储空间。尽管如此，将它们存储在单独的表格中也可能是浪费的，如果通用属性可以存储在单个列中的话。

这是一个棘手的问题，甚至承认，更不用说处理。我在数据/对象建模方面的经验并不多，因此真正了解他们所做工作的人的意见会很有帮助。谢谢:)

Answer 1

你既涉及疑问，面向对象（编程）造型方面数据库建模方面。我们从抽象的角度出发。

你说：

1）这两个实体有着许多相同的属性，但在其他未找到一些独特的。

2）一个不是另一个的超类型或子类型。

和：

3）的重叠不是由于对象继承。

但是请注意，继承应该不要与亚型混淆，即使很多时候他们绑在一起！例如参见维基百科的Inheritance (object-oriented programming)，其中该语句由两个引用[1，2]支持。换句话说，即使A不是B的子类型，而B也不是A的子类型，也可以找到A和B都从中继承属性的C。

所以，你能想到或没有这个C作为A和B的“抽象父”;但无论如何，至少从数据库的角度来看，将其视为共同的祖先是很方便的，因此将“通用性”中的常见属性因式分解。然后，从面向对象编程的角度来看，你可以将A或B看作是C的子类型，或者简单地看成是两个不同的东西，这取决于你的对象关系映射工具的特性，以及手边的问题等等。

当然，这种对事物进行建模的方式并不禁止A和B除了继承C之外，还有一个或多个它们之间的关系，就像你已经完成的示例Products-Projects一样。

所以，这里是我的回答您的四名决赛的问题：

1）是的，它被称为继承。

2）您可以检查两个实体是否有大量的通用属性。 3）你可以在数据库中用一个公用表建模它们，这可能有一些共同的属性，如完整性约束，并且有两个表有一个外键。当然，这条规则不是盲目应用的，而是可以与所有人类规则有所不同。从编程的角度来看，另一方面，你可以决定使用超类型还是不使用超类型。这取决于很多因素，应该根据具体情况来决定。