数据库设计中的耦合与内聚

Question

假设有两个模块用户和状态。我将这两个模块拆分为以下2个案例 这是 case-1

这是案例-2

我试图了解哪种数据库设计低度耦合，应该根据软件工程设计原则采用？特别感兴趣的是，通过考虑可重用性来评论哪种方法更好。我的意思是将来哪种方法可以轻松重复使用＆amp;有效地对任何其他软件设计

Answer 1

您的案例都有一致性问题，而不是耦合/凝聚力问题。

首先，您的案例都允许部门拥有无限量的状态。例如，如果状态表示部门是打开还是关闭，这可能没有意义。如果部门在任何给定时间只能有1个状态，那么状态的主键必须是dept_id（在这种情况下，它应该在departments表中作为具有可用状态的表的外键），这可能是不正确的取决于你的建模。但是，对于一致性，第二种情况更糟糕，因为它允许您为变量状态设置无限量的值（没有用于定义状态有效值的表，因此这种情况允许您甚至打错字，例如一个有状态的部门＆＃34; opne＆＃34;而不是＆＃34;打开＆＃34;）

其次，用户表与其余数据没有关系，这可能没有意义（用户不能成为任何部门的成员等）。在第一种情况下，用户没有状态，在第二种情况下，它与状态表有关...两种情况（对于用户表）都没有或多或少与另一种情况相关（因为它与其他任何东西都没有关系）您的模型），但是您需要检查您是否希望用户具有状态（以及该状态是什么，是否应该从固定的值列表中选择）。

我们在分析两种情况下的耦合/凝聚力方面还有很多工作要做。您必须更好地了解您要模拟的内容，并且应首先担心确保consistency。

如果您想阅读一些内容，这是一篇简短而有趣的关于耦合/凝聚力的博文：https://thebojan.ninja/2015/04/08/high-cohesion-loose-coupling/

希望它有所帮助！