数据库需要关系

Question

在Microsoft零售管理系统中，如果我们检查数据库，它不会使用以下任何一种关系：

一对一

一对多

多对多

一位专家告诉我，有时关系是有害的，因为它在我们的日常生活中是有害的。因此，避免在生活和数据库中的关系。我仍然认为这是一个笑话。

所以，请告诉我，什么是真正需要使用关系甚至同样的事情，我们也可以通过查询管理等。

Answer 1

关系（ER模型）是好的，因为它们描述了你的模型 - 简单地说你可以更容易地看到哪些实体在彼此相互连接的图上彼此相关。

至于关系是否应该有外键（存储模型），那么答案是：它取决于。

这取决于关系的本质。在我工作的公司，我们遵循以下规则： 仅在用户定义的实体之间创建FK（对于对他有意义的关系，如客户 - 订单），避免系统自动添加的实体上的FK（如日志/审计条目，特别是如果有很多）。

如果您有外键，这可能会影响删除实体时的性能，因为数据库必须检查此实体是否“未使用”。这需要花费与执行适当的select语句相同的时间。

Answer 2

relational-database和entity-relationship几乎没有任何关系。

关系数据库由一组或多组事实组成，组织成关系。在这个模型中，关系只不过是一堆与事实相同的“事实”。为了确保数据库中表示的事实集合是有效的，通常会有一些额外的约束应用于事实的表示方式。首先，事实必须是可识别的，每个事实都应该有一个“关键”，对于任何可能的关键只有一个这样的事实。另一个是，当一个事实提出关于另一个事实的主张时，肯定是关于（被告）的事实存在并且同意“元事实”。

作为上述例子，您当然不希望自己处于这样的位置，即您知道“客户10的付款时间落后15天”，但您不知道哪个客户10落后于其中，因为它们不止一个，或者根本就没有客户10。这些约束用于强制数据库“一致”。

---

另一方面，实体关系仅在应用程序设计方面有意义。它是描述抽象程序组件如何相互关联的“语言”。关系数据库通过功能依赖性提供了一种对“is-a”，“has-many”，“属于”设计进行建模的方法，但它绝不是唯一的一种。另一个例子是面向对象设计中使用的继承和组合。

值得注意的是，一个应用程序可能有几个类，这些类彼此足够独立，不需要任何组合或继承，类似地，数据库可能没有功能依赖，但仍然是一致的。

尽管如此，这些应用程序可能既小又不常见;这些工具为设计“好”应用程序的任务提供了一些重要的价值，而且几乎所有这些工具都会对这些工具进行一些，甚至可能的广泛使用。