ER图的重要性

我是一名学生，并且正在作为学术界的一部分开发多个项目。

在为其中一个项目开发数据库时，我们遇到了一种情况，即我们在考虑是否需要ERD。目前，并不是我们每个人都同意先开发ERD，然后再从中开发数据库。

大多数人都喜欢直接根据书面要求在系统上实时地开发数据库。

现在，我是数据库原则的严格追随者。我认为该数据库应仅从ERD开发。因此，我只想了解以下内容：

• 业界是否遵循这些原则？
• 我只是在浪费时间开发ERD吗？
• 开发ERD有什么好处？

简单明了，将没有ERD的数据库视为没有建筑计划的房屋。这样做是可行的，因为您认为将砖砌成一个砖就足以建造一些东西，但是当其他人对项目负责时，就有可能发生灾难。

以我的经验，除非将ERD与CASE工具（ERWin，MySQL Workbench等）结合使用，否则您将不会从ERD中获得太多收益，ERD还可以使您执行一些非常有用的操作，例如正向和反向工程。即使没有这些功能，完整数据库的集中示意图也很有用，因为有时在数据库本身中实现的约束不足以讲述有关特定数据库实体之间关系的完整故事。

这是一个涉及MySQL的示例，您可能知道它实现了多个内部存储引擎，最著名的是MyISAM和InnoDB。它们之间存在显着差异，其中最重要的差异之一是MyISAM不支持约束。尽管如此，MyISAM还是大量用于Web应用程序，这意味着关系逻辑需要通过业务逻辑（应用程序代码）或以其他方式来实现。问题是，当您使用MyISAM表（实体）对ERD进行前向工程设计时，MySQL将默默地忽略ERD设置的约束，最终您将得到一个数据库，该数据库无法清楚地标识实体之间关系的性质。换句话说，开发数据库布局之后，如果没有ERD，代码开发人员将无法实现适当的业务逻辑。

ERD非常高兴能够清楚地了解您的数据库结构。除了对您的项目而言是重要的文档工具外，它还使您在需要实施查询（尤其是表之间的联接）时更加轻松。想象一下，有一个双监视器配置是多么的好，在左侧有ERD，在右侧有查询编辑器。您可以清楚地看到表之间的关系，并据此编写查询。如果您的数据库项目非常简单，并且您的项目不需要它，那么没有它就可以生存。

ERD将为您节省比您想象的更多的时间。

如果几年后在没有ERD的情况下进入数据库，则必须花费大量时间来查看项目中正在发生的事情。

我有公司，我们设计ERD，千万不要在没有ERD的情况下考虑数据库（实际上这是我自己的个人实验）

ERD曾经在一段时间前变得更加主流。IMO他们现在或多或少是可选的。

当前，一些非常成功的团队根本不理会ERD，但提供了出色的系统：强大，高效且易于长期维护。在敏捷开发中，尤其是当我们从一个简单的工具开始时，这尤其如此。

当然，ERD是一种很好的沟通方式，但绝不是唯一的方式，或者在所有情况下都是最好的方式。一些团队更喜欢其他方式的文档记录和交流。

这个行业没有一揽子规则。

在编写生产代码之前进行设计很重要。原型制作也很重要；数据库人员通过编写SQL来开发原型。（还记得弗雷德·布鲁克斯（Fred Brooks）关于原型的说法吗？）

图形语言（仅ER之一）尚未被证明非常擅长以一种易于理解的方式捕获数据库的所有语义。

除了开发人员之间，它们还没有被证明是非常有效的通信工具。但是在设计数据库时，关键的沟通不在开发人员之间。它是在开发人员和领域专家之间（在开发人员和业务人员之间）。

对象角色建模（ORM）具有图形语言，但是它基于“事实”（简单的句子）。商界人士可以很容易地验证事实。业务人员无法轻松地验证ER图或ORM图。