前言

笔者之前对数据库的了解比较偏理论（如关系模型、范式、增删查改、join语句等），后来做一些小demo的时候也总是navicat点点点就解决，而因为没有超出认知之外的、较大量数据的检验，只是用自己随手写的一些测试用例，所以我也一直没有发现使用数据库时可能会踩的坑。 直到最近，我被分配了一个小任务，做一个简单的查询系统。最初我粗略地看了一下原始数据就吭哧吭哧开始设计了，结果后期自己录入数据测试以及将同学整理好的一些数据导入时才发现有很多以前没有考虑到的情况，而重新更改数据库字段以及在java的分层结构下逐层往上改的过程中更是bug不断（但其实这些bug是设计失误导致的，原本可以避免，所以有经验的人可以少走很多弯路）。特此记录。crud不是终点，但确是后端的起点。要脚踏实地，一步一个脚印。首先要保证系统的正确性和可靠性，然后才谈其他高级特性。

Navicat

Navicat不是数据库，它只是一款数据库的管理工具，可以理解为是后端的低代码开发雏形。用户在它上面的每一个点点点操作，都对应了一条SQL语句。一般被用于快速建库建表。

Navicat需要付费，但是破解码在网络上满天飞；现在也有了很多国产的替代工具。

Double字段

• 在Navicat中，有一个长度和小数点字段，如果是Double类型，则小数部分对应小数点字段的位数，整数部分则是长度-小数点位数的位数。
• 勾选了“填充0”选项：如果长度设置合理是没问题的。

比如预估被输入的数据只会是小于10的正整数，约到小数点后一位，那长度设置2位即可（或者保险点设成3位），此时整数部分不会填充前置0，小数部分会填充0；但如果设置成了很大的数或者默认的255，数据就变成了很多个前置0，查询出来的结果只剩0。

varchar字段

虽然曾经看到过一个开发规范说：字段能用数字型就不要用字符型，因为数据库处理开销大。但是实际项目中，有很多意想不到的情况。比如插入了一条信息数据，显示它的阶段是1-8，肯定是用varchar作为字段类型更好。因为总不能要求录入数据的人放着"1-8"这么好用的表达不用，非要把八条除了这个号码不一样之外其他钱都一样的数据录入一遍吧？总别要求前端也再解析一下这个符号然后分情况插入多条数据吧？那万一是1、2、5之类的更复杂的呢？总不能一一解析吧？而且目前系统最大的功能就是查询，只需要用数据库的like做一个简单的模糊查询就可以了，varchar完全能满足要求。

于是新的问题出现了。直接改了数据库字段和对应实体类之后，乍一看似乎没别的需要修改了。但实际上，直接运行后会发现查不到任何数据，而输入对应的筛选条件后又能找到。

这说明可能是表单传数据时被默认传了字符'',需要将这种情况过滤掉：

于是在xml对应sql语句中写入：

<if test="xxx != null and xxx != ''">#{xxx},</if>

其中，xxx是字段名。

至此，和数据类型相关的问题就结束了。也感谢你能看到这里！