19年加油，以及再谈三范式

       年初做了一段时间运维工作，BS海外系统，小集群，香港和北京各十几台服务器。起初是各种头疼，用了挺长时间，总算是入门了。这才有能力在上班之余，每天抽出几十分钟跑一个奥森南园。之后被叫过来参与了朝阳门的一个小项目，交通、行业、技术等各种因素吧，很煎熬。。。

         笔者也从中失去了兴致，正赶上雄安新区招收事业编制，报名，准备，参考，昨天出的成绩，差了3分，没能进入面试。不可惜，毕竟呢公务员这东西，笔试进不了前三名是没啥用的。

         两周的备考时间里，考试资料中的两句话使我受益匪浅。

         第一是党的十九大报告指出——发展是解决我国一切问题的基础和关键

         第二是一支国外团队圣诞节坚持工作时说的——能够参与雄安新区的规划,一个圣诞节算什么？

         一个人的发展是需要动力的，这个时代要尽量远离拉低你下限的东西，不断地提升自己的上限就够了！今年的博客，要抓紧把前面的几个系列收尾了，还有上周帮公司写了个React开发中后台系统的demo，发现React16.3之后，实在是惊艳。而年初积累的运维方面的经验，还是要趁机巩固一下，有打算写一个工具系列(svn/git/sonar/Jenkins/JIRA/Docker等等)，那这个系列的主角必然是Docker了,有兴趣的话，提前准备好CentOS环境吧。

         2019，共勉！

 

PS:这里说一下数据库的设计吧：

         用户表(编号,姓名)，科目表(编号,名称)

         需求——结算单(编号,用户编号,用户姓名,科目编号,科目名称...)

         那么——结算表(编号,用户编号,用户姓名,科目编号,科目名称...+时间戳，状态，逻辑删等数据库相关的字段)，反正字段会比业务只多不少！

          这个时候有外行冒出来说你这个违反了三大范式[1],并随手百度出某篇不知道从哪里扒来的已经被转过几万次的博客，你的结算表里用户姓名和科目名称传递依赖！尽管你费尽心思，给大家讲解到底什么才是三大范式，但是人家不听呀，毕竟博客为证，“铁证如山”！

          所以呢，查资料时还是多找些文章对比着看吧，重点是原创博客，作者的等级高一点的，最起码不低于四级吧，比如笔者的博客。。。。。。

 

[1] 事实上结算表中的用户姓名和科目名称是结算表自己的特性，和用户表中的姓名，科目表中的名称是两个概念。比如两年前的一张结算单，姓名：张三，科目：差旅费，两年后，张三改名张小三，而科目表中的差旅费那一项已经被管理员删除。但是这些和结算单没有任何关系，再次打印两年前的那张结算单——姓名：张三，科目：差旅费，够清楚了吧！