我是一名学生，我正在开发几个项目作为我学术界的一部分。
在为其中一个项目开发数据库时，我们遇到了一种情况，我们考虑是否需要 ERD。现在，并不是每个人都同意先开发 ERD，然后再开发数据库。
大多数人更喜欢直接根据纸上要求的系统口头开发数据库。
现在，我严格遵守数据库原则。我认为数据库应该只从 ERD 开发。所以，我只想知道以下几点：
- 行业是否遵循这些原则？
- 我只是在开发 ERD 上浪费时间吗？
- 开发 ERD 有什么好处？
AskOverflow.Dev
我是一名学生，我正在开发几个项目作为我学术界的一部分。
在为其中一个项目开发数据库时，我们遇到了一种情况，我们考虑是否需要 ERD。现在，并不是每个人都同意先开发 ERD，然后再开发数据库。
大多数人更喜欢直接根据纸上要求的系统口头开发数据库。
现在，我严格遵守数据库原则。我认为数据库应该只从 ERD 开发。所以，我只想知道以下几点：
简单明了，将没有 ERD 的数据库开发为没有建筑计划的房屋。这可能是可行的，因为你认为简单地把一块砖放在另一块上就足以建造一些东西，但是当其他人对项目负责时，就有潜在的灾难。
根据我的经验，除非您将 ERD 与 CASE 工具（ERWin、MySQL Workbench 等）结合使用，否则您不会从 ERD 中受益匪浅，这些工具还允许您执行一些非常有用的操作，例如正向和逆向工程。即使没有这些功能，具有完整数据库的集中示意图也是有用的，因为有时在数据库本身中实现的约束不足以讲述有关特定数据库实体之间关系的完整故事。
这是一个涉及 MySQL 的示例，您可能知道，它实现了几个内部存储引擎，最著名的是 MyISAM 和 InnoDB。它们之间存在显着差异，其中最重要的差异之一是 MyISAM 不支持约束。尽管如此，MyISAM 被大量用于 Web 应用程序，这意味着关系逻辑需要通过业务逻辑（应用程序代码）或以其他方式实现。问题是当您使用 MyISAM 表（实体）对 ERD 进行正向工程时，MySQL 将默默地忽略 ERD 设置的约束，您最终将得到一个无法清楚识别实体之间关系性质的数据库。换句话说，在您开发数据库布局之后，代码开发人员无法在没有 ERD 的情况下实现正确的业务逻辑。
ERD 非常适合清楚地了解您的数据库结构。除了对您的项目来说是一个重要的文档工件之外，它还可以在您需要实现查询时简化，尤其是表之间的连接。想象一下拥有双显示器配置是多么美好，左侧是 ERD，右侧是查询编辑器。您可以清楚地看到表之间的关系并据此编写查询。如果您的数据库项目非常简单，并且您的项目不需要它，也许没有它也可以。
前一段时间，ERD 曾经更加主流。IMO 他们现在或多或少是可选的。
目前，一些非常成功的团队根本不关心 ERD，但提供了出色的系统：从长远来看，健壮、高性能和易于维护。在敏捷开发中尤其如此，当我们从小处着手时，使用一组极简的工具。
当然，ERD 是一种很好的沟通方式，但绝不是唯一的方式，或者在所有情况下都是最好的方式。一些团队更喜欢其他的文档和沟通方式。
这个行业没有一揽子规则。
ERD 将为您节省比您想象的更多的时间，如果您在运行中执行所有操作，那么当您想要生成联结表时，您会卡住。
如果几年后您在没有 ERD 的情况下遇到数据库，您必须花费大量时间来查看您的项目中发生了什么。
我有公司，我们设计 ERD，不要考虑没有 ERD 的数据库。（实际上这是我自己的个人实验）
在编写生产代码之前进行设计很重要。原型也很重要；数据库人员通过编写 SQL 来开发原型。（还记得 Fred Brooks 关于原型的说法吗？）
图形语言（ER 只是其中之一）并没有被证明非常擅长以一种易于理解的方式捕获数据库的所有语义。
除了开发人员之间，它们还没有被证明是非常有效的通信工具。但在设计数据库时，关键的沟通不在开发人员之间，而是在开发人员之间。它在开发人员和领域专家之间（在开发人员和业务人员之间）。
对象角色建模 (ORM)具有图形语言，但它基于“事实”（简单句子）。商界人士可以很容易地验证事实。业务人员无法轻松验证 ER 图或 ORM 图。