是什么限制了你的想象力？

之前在做两个产品之间的数据迁移工作。两个产品功能类似，前一个是一个已经开发运行了超过10年的技术架构，Java + RMDB + Websphere Application Server，后一个是近期正在开发中的技术架构，node.js + loopback + MongoDB + kubernetes + Docker 等。

接到任务后，我把老产品的数据库表设计逐个捋了一遍，把每张表每个字段列出清单；把系统中跟数据定义相关的代码，浏览了一遍，把数据可能的限制和使用方法都总结了一下；然后还搜索了相关的官方文档和内部网站上相关的网站，争取了解到业务相关的背景、定制说明和方法；除此以外，有疑问的地方，还找到了老产品的dev一一去澄清。同时，我把新产品的代码拉下来，跟对方的dev lead沟通了新产品的设计，列出了数据的特点和需要迁移的数据在新老系统之间的映射关系，然后其中一件事情，我们是这样设计的。

之前的系统中有很多张存储code信息的表格，例如国家、部门、员工类型、组织、工作地点等。因为新产品在用MongoDB，而MongoDB的文档是什么灵活的，为了简化系统设计，我跟新产品的dev lead约定在系统中使用Enum来保证数据可靠性，在数据迁移的请求中，将该Enum的定义一起发送过去。

大家都对这个设计非常满意，然后我们就开始各自的coding了。虽然对node.js 还没有过去的java使用的那么顺手，但是一周之后，功能还是做好了。我连上了常用的测试环境，发现程序运行良好。美滋滋的心情溢于言表。然后决定连上一个从产品环境复制下来的数据库进行大数量的测试。

看到一行一行的log打出来，成就感就不用提了。就在这时，感觉看到了跟上一次测试不同的log：413： Request Entity Too Large。

What's it?!!

进一步看response，原来是请求太大了，再来排查原因，原来是因为我们对于这些code的数据量太没有想象力了！在做设计的时候，我们所有的假设都是这些数据顶多几百个，绝对不会超过几千个。正常的公司的数据不是都是这样么？

可是，我重新写了sql语句去查询数据库，得到了下面的结果：

[db2inst1@w3pdb01 ~]$ db2 "select count(1) from empinst.emp_type"   //员工类型44个

 

1          

-----------

         44

 

  1 record(s) selected.

 

[db2inst1@w3pdb01 ~]$ db2 "select count(1) from empinst.country"   //员工所在国家244个

 

1          

-----------

        244

 

  1 record(s) selected.

 

[db2inst1@w3pdb01 ~]$ db2 "select count(1) from empinst.department"  // 员工所在部门64061个！！！ 这就是罪魁祸首啊！！！

 

1          

-----------

      64061

 

  1 record(s) selected.

 

[db2inst1@w3pdb01 ~]$ db2 "select count(1) from empinst.organization" //员工所在组织/子公司，1067个

 

1          

-----------

       1067

 

  1 record(s) selected.

 

[db2inst1@w3pdb01 ~]$ db2 "select count(1) from empinst.workloc" //员工工作地点15842个。虽然这个数据一样会导致413错误，但是跟前面那个6W多的数据比较，我根本不把它看到眼里好么？

 

1          

-----------

      15842

 

  1 record(s) selected.

 

虽然我已经在公司工作了很多年，知道公司人数众多，机构庞大。但是，但是，但是，我对公司能查出6W多个部门没有任何思想准备好吗？

接下来只好重新跟新产品的dev lead商定新的设计方案，还是得像老产品一样用一张表来单独存储这些code。

于是，新的一周coding又开始啦！

做软件就是这样，总有意外发生。你以为你已经思虑周全了，还是会有遗漏的内容。唯一不变的就是变化。