清洁的数据库
首先，这篇文章讲的是关系型数据库。其次，关于OLTP数据库--在线交易处理数据库。这意味着文章将描述一些重要的原则，即如何将你的数据库设计成快速、灵活、易于使用的常规业务操作。请注意，OLTP数据库的业务操作意味着每个操作通常只需要一个实体。所以，一个干净的OLTP数据库意味着你的数据库被正确地设计为一个SOLID代码。
文中简要地解释了数据库设计中的一些关键点。
表的单一责任原则
记住，数据库中的所有对象都应该遵守单一责任原则。当你思考如何组织你的实体和DAO类时，它更容易理解。如果你的数据库中的表不符合SRP，你就不能轻易在DAO类中遵循SRP。所以，设计OLTP数据库的第一条，也可能是最主要的一条规则就是完全依靠SRP原则。
而有时，如何根据SRP来准备你的表并不那么明显。让我们检查一下一个客户表。
乍一看，这看起来是没有问题的。但仔细观察，我们可以发现这个表由两组不同的字段组成：第一组只是用于客户登录操作，第二组包含通常由另一组操作要求的联系信息。
再深入一点--你也可以有一些实际上不需要地址或登录尝试的服务账户。此外，你还可以在未来添加一些额外的字段，如last_activity、presige_level等等。而对于每一种类型的操作，你需要检索每个客户的所有数据，即使是登录尝试或电子邮件搜索，也是为了通知的目的。这不仅仅是对数据库来说比较困难，而且还使你的对象更重，代码更繁琐。
此外，一些数据库（例如PostgreSQL）在每次更新操作时都会重写整个行，即使你只改变一个布尔字段。这意味着，如果你的表由100列而不是10列组成，那么它在每次更新时将写入10倍的数据。并且比你分割表的时候写得更频繁。最后，在最坏的情况下，与小表相比，数据库会多写几十次数据。
如何正确设计呢？比如说。
或者客户-地址关系可能是多对多的。在这种情况下，你也可以为系统中的其他实体使用地址表，并使用相同的功能和用户界面来更新不同对象的地址。最后，我们有一组不同的操作，对于每一组操作，我们都要操作一组不同的数据。而且更重要的是，一般来说，我们的操作在数据库下的磁盘上产生的工作量更少。而且，每个操作被其他操作阻挡的情况也少得多，因为从数据库的角度来看，他们是在处理不同的表。
最后，我们有了一套更灵活的表，它们在数据库上产生的工作量更少，并且给了我们回旋的余地，可以编写更多符合SRP的代码。一个额外的好处是，我们的表就是更轻了，在未来的迁移中，每个ALTER TABLE 查询的执行速度会快很多。
列的单一责任原则
同样的原则对列也适用。让我们来看看下一张表。
有时候，开发人员决定为表增加额外的功能，以避免迁移。在上面的例子中，有一个操作类型为received 和sent 的表。为了避免迁移，有人决定增加一个额外的标志，并把它放在字段operating_type中。例如，b2b标志。现在我们有received,sent,b2b received, 和b2b sent 。
从某种角度看，这可能是合理的，但接下来会发生什么？例如，我们需要添加一个操作奖励。我们是否应该添加bonus" 和b2b bonus" ？如果一个奖金可以被接收，也可以被发送呢？它应该是8个可能的值吗？(2 forreceived andsent) * (2 forb2b andnon-b2b) * (2 forbonus andnon-bonus)。在逻辑中应该如何管理？
我们不应该在一个字段中混合不同的功能和标志。
NULLs
有一条重要的规则--避免出现NULL。让我们再看一下transaction 表。
这些_on 字段看起来像一些枚举。它们也只在状态改变的操作中被更新，在下一个通常的操作或状态改变中需要。如果我们需要再增加4个状态？再增加4个列？那么，为什么我们要把这些数据存储在如此重要和沉重的表中，如transaction 呢？可以改成一组2个表。
在这种结构中，我们实际上是在核心表之外提取了一半的数据，而不会丢失任何数据。另外，我们还增加了一些新的机会来增加一些额外的数据。例如，我们可以添加user_id ，并记录改变交易状态的用户。
清洁的数据库
关于设计数据库以优化操作，还有其他要点，但这是另一篇文章的主题。
设计一个干净的数据库是工程师工作的一个非常重要的部分。当数据库已经填满了数据时，要改变数据库的结构就更难了。数据库组织得越差，就越难保持设计的干净。所以要尽可能早地做。
相关故事
l o a d i n g
. ..评论及更多!
