系统设计中的数据库设计

Question

最近，我们讨论了rough DB模式(高级表和列)设计是否应该是系统设计阶段的一部分。

我们在公司里有两种对抗的方法。让我们假设系统设计包括设计队列、Lambdas、与其他微服务的集成等。

方法1)在系统设计中，我们还应该包括(至少是粗略的想法)数据库中的表、关系表和规范化表。

方法2)在系统设计期间，我们应该只说明DB存在，仅此而已。稍后的DB模式将在逻辑实现并需要持久化之后自然发展。

你认为如何？

Answer 1

在设计的任何阶段，对你的目标有一个粗略的认识是永远不会错的，只要它是一个粗糙的想法，一个概念在一张纸上，没有刻在石头上。如果某些表和属性可以帮助您获得更清晰的画面，您也可以想象它。但是，确保团队中的每个人都把它看作是什么，尤其是它不是什么:它不是事后必须构建的蓝图。

当谈到具有属性、关系和规范化的表设计时，最好只实现数据库当前迭代所需的部分，支持为下一个版本计划的用例或用户故事所需的持久性，而不只是因为它在前一个概念中。

通常情况下，原来的“远景”大致是正确的，但细节却是完全不同的，所以团队会高兴的是，不必在实现级别上解决太多的差异。

因此，简而言之:当你采取正确的观点时，在你的问题中提出的两个备选方案不需要有分歧。

Answer 2

我认为数据模型是大多数设计中必不可少的一部分。这意味着您已经在您正在设计的系统中表达了主要实体及其关系。如何将现实世界的问题和解决方案映射到计算机程序？在团队中工作时，如果您在编写代码时还没有弄清楚如何解决问题，那么您很快就会失败。

当我读取数据库表、列时，这些都是实现工件。没有必要把这一切都写出来。您注意到需要一个持久化层。

有几个例外。有时，数据结构是由现有设计决定的。有时它们是通用的，就像日志文件一样。在探索性设计中，可能没有足够的信息。但它们从来都不是“显而易见的”--当“显而易见”时，任何两个开发人员都会编写截然不同的实现；)