数据库宽表和窄表的选择与设计

• 窄表：严格按照三范式设计的表，没有多余字段。每个表的字段对应实体的一个字段，复杂对象需要联表才能获取到。
• 宽表：反范式设计，查询不需要联表就可以获得所有字段，查询的速度较快。

数据库设计，基本上按照规范来不会有什么大问题。但是当我们做的项目多了，代码写的多了之后，总会感觉到数据库设计有很多需要优化的地方。最近维护老项目的代码，项目的数据库设计导致有些功能相当复杂，优化起来也很麻烦。

就比如一些日志表被拆成了窄表，可能能节省一部分空间。但是用起来真的是相当麻烦，因为日志一般都是用来分析的，查询功能很多，查询的条件也很多。在查询的时候要进行联表，每次功能改动，都要维护SQL，而且在后期数据量变大了之后查询速度就很慢，优化起来相当费劲。

如果设计的时候设计成宽表就会很方便，首先是查询的SQL会变得很简单，如果使用了mybatis-plus可能一句SQL都不用写。然后就是不需要联表查询了，这样查询速度会快很多。

可能有些人会担心直接存一张宽表，数据就不是关联表的实时数据了。首先我们应该考虑一下，这个表是否真的需要实时的数据，毕竟日志表其实记录的是历史数据。然后可以考虑一下关联的表中的数据更新频率如何，如果更新频率很低，也可以把改动广播到日志表中。特别是一些字典，直接存真的很方便。

这里科普两个名词

• OLTP（联机事务处理）：业务系统的修改操作的并发量比较大，这时候窄表操作起来比较方便，能支持的并发量也比较大。
• OLAP（联机分析处理）：业务系统的查询功能比较多，这时候使用宽表查询效率比较高。

当然一般来说，我们的业务系统中两种业务功能基都是存在的。这时候，我们就要考虑某些表是不是应当首先支持OLTP的业务，或者优先支持OLAP的业务。在并发量和数据量都比较小的情况下，我们选择宽表或窄表区别都不大，两种业务都能支持。在并发量或数据量比较大的时候，这时候我们就要考虑，那种业务需要优先支持，哪种业务优先级可以放低。

还有种情况，两种业务优先级都很高，两种业务都需要支持。这时候，就需要额外的设计了。我们可以引入消息中间件同时建立窄表和宽表支持两种业务，或者使用内存型的数据库或搜索引擎提高处理速度。也可以依靠数据中心支持分析业务。