系统设计之数据类型选择

前言

最近在网上见到一个关于REST设计中status字段用字符串还是数字的讨论帖,自己也参与其中聊了聊,有感而发决定整理一篇文章记录下来,这类问题并没有什么标准答案,这篇文章也是作者一家之言,希望读者可以多思考、多讨论,不要盲目遵从or否定。

数据库设计

大多数互联网系统设计的起点,便是数据库设计、数据模型设计,这个过程中必然会面临各种statustype等枚举类字段的数据类型取舍问题,考虑这种问题的关键点在于性能扩展便捷

性能

在讨论中,看到许多人强调字符串性能感人,这种不严谨的调侃语真的让人很无奈。一方面是不正经,中文环境的技术氛围大概都是如此吧。另一方面是毫无根据,DB性能的关键在于磁盘IO,难道4字节的数字比4字节的字符串读写快很多吗?

针对这个问题,我甚至专门进行了性能测试。事实上在存储空间相同的情况下,字符串与数字的性能并没有什么差别。

扩展

使用数字表示状态等类型时,为了保持可扩展性,常常需要预留多个整数位,比如1001这样,这样的数字管理其实挺麻烦的,尤其是错误码之类枚举值较多的业务场景,而字符串的扩展性体现在变长与格式灵活。

便捷

说到便捷,字符串的优势就无与伦比了。对于我这种记忆力较差的人,一个订单表中5个枚举字段全是数字,真的是让人一头包。

特殊类型

比如MySQL提供了自己的enum类型,这种类型集合了字符串与数字的优势,在MySQL环境下使用起来没问题,但是涉及到其他类型的数据库or数据仓库等就不那么方便了。

分布式调用

在分布式环境的微服务之间调用时,常常需要整理一套状态码标记服务方不同的状态反馈。前后端调用的API接口也需要设计状态码。

在这种环境下,数字就更加没有必要了。因为数字常常需要序列化为字符串传输,序列化之后的数据优势就更小了,这也是为什么许多OpenAPI的错误码等都直接使用字符串。

简单举例,开发时你愿意看到10020还是NOT_LOGIN这种错误码?

再谈性能

系统设计时,万万不要沉溺于虚假的性能优化。在项目的系统设计中,我见过有人为了使用tinyint还是smallint而与所有人争辩的脸红脖子粗,这种看似很有原则、对性能很敏感的做法,其实是捡芝麻丢西瓜的毒瘤。

许多情况下,这种1字节、2字节的优化对性能并没有什么帮助。技术人员要理解自己提供的服务的性能瓶颈,也需要明白系统底层IO的原理,你以为自己节省了1字节,但是DB读写的数据块大小并没有变化,而网络传输时因为int转换为string而更多的消耗资源。