当涉及数据库时，聚合是如何工作的？
因此，我正在读一本关于设计模式的书(Design解释了第二版)，而且在整本书中，它都说“喜欢聚合而不是继承”。
我正试着设计一些东西，我觉得自己太蠢了。
所以从概念上讲，我有Recruiters。我想这些招聘人员可以是抽象的，因为我有几种不同的招聘人员.全职和兼职。问题是，我希望每个招聘人员都能找到其他招聘人员的推荐信，因为他们可能会一起工作，需要共享和合并信息。
每个招聘人员都会有一个或多个他们负责的Regions，也许与其他招聘人员共享。所有的区域都是SubRegions的概念集合。SubRegions定义了沿着特定地理边界的地方。这些数据包含了关于整个SubRegion招聘情况的一些数字统计信息。
分区域由Recruitments组成，其中包含关于SubRegion特定招聘事件的详细信息。它们还包含其他统计信息，这些信息在招聘中是有意义的(因为它们对招聘非常具体)，而不是在SubRegions下。每次更新招聘信息时，它都需要创建一个新的交易记录，这样我就可以保存数字调整的历史。
现在，我希望所有这些都能够存储在数据库中。当涉及到数据库设计和结构时，我非常天真，特别是在处理对我来说是新的抽象类和接口时。
数据库中的所有内容都将以某种方式在不同的表之间进行链接。比如说，招聘人员将是一个表，还有一个区域表、一个SubRegion表和一个招聘表。
我需要将逻辑放在哪里，以及如何将逻辑放在哪里，这样我就可以确保将所有东西保存到数据库中，这些数据库很好地连接在一起，但在代码中却是松散耦合的。
回答 2
Software Engineering用户
发布于 2013-10-09 01:43:15
我认为您可能将编程语言中的对象与数据库中的元组混淆。数据库中没有对象继承，除非它是面向对象的数据库。虽然您可以在面向表的数据库中模拟继承，但通常不会这样想。如果是的话，我们将其命名为1:1关系，其中招聘人员是主表，AdvancedRecruiter (或类似的东西)是链接表，其中包含属于子代对象的附加信息。
当您在数据库中设计类似的东西时，您必须问自己的问题与您在用编程语言设计继承层次结构时问自己的问题是一样的。问题是，是否存在与某种形式的“增强”招聘人员相关联的数据或行为的集合，这些数据或行为不属于主招聘对象，而是主招聘对象的自然子集？如果你有这个(我怀疑你没有)，那么你就有了一个继承的候选人。如果没有，那么只需创建一个招聘人员表，并将有关招聘人员的所有信息都放在其中(除了与招聘人员有1:多关系的事物列表外)。
您所说的“支持聚合而不是继承”--我一直听说过其他的东西：“偏好组合而不是继承。”它的意思是，只要有可能，就应该组合对象；也就是说，通过让它们通过各自的接口相互交谈，或者让一个对象保存对另一个对象的一个或多个引用，从而将它们以有用的方式组合在一起；而不是让对象彼此继承。组合更倾向于松散耦合和更高内聚性的代码。但是，所有这些都与数据库没有多大关系。
Software Engineering用户
发布于 2013-10-08 00:57:08
表主要描述关系，而不是必要的对象。您的设计包含以下关系：
Recruiter n:m Region
Region 1:n SubRegion
SubRegion 1:n Recruitment…每一张都可能是一张自己的桌子。招聘人员和区域等的实例在这里由ID引用。给定一个对象，它可以通过其ID在数据库中查找属性：
我是14分区。我的招聘人数是多少？从SubRegion_Recruitment选择招聘，其中SubRegion = 14
当然，您可以通过类似于数据访问对象或类似的东西来抽象这一点。
https://softwareengineering.stackexchange.com/questions/213702
复制相似问题
腾讯云开发者
