这是我参与更文挑战的第11天,活动详情查看: 更文挑战
初衷
首先说明一下,这系列的专栏是从《High Performance MySQL》原书第三版中的几章内容中翻译而来,当然也根据自己的理解加了一些额外的说明、解释和示例。之所以要重新去深入了解 MySQL,其实是发现很多业务开发的问题往往回过头来会发现数据表本身设计就会有问题,一开始的错误导致后面无穷尽的查漏补缺,过程十分痛苦。因此,自己决定重新再来梳理一遍 MySQL 的知识,于是就选了《High Performance MySQL》来学习。而之所以选择使用原版,其实是两个方面的原因:一是逼着自己的英语阅读水平恢复一点点(除了开源代码的说明文档,很长时间没有仔细阅读英文文档了);二是借着翻译的过程让自己的理解能够加深一些。
过程
过程其实是挺漫长的,如果从第一篇稿(那时候是在语雀写)算起,已经有近半年的时间。最开始是打算一周一篇的,后面移到掘金的时候发现还挺受认可的(5月还获得了掘金优质专栏),于是就更改了频率。这就导致晚上下班的时间大量被占用,乃至被我家小孩误以为我天天加班,时不时来敲击键盘捣捣乱。其实,我也知道他是想让我陪他玩,但有时候还是会警告他不要打扰我。结果引得他拿了一张纸写了好多“警告爸爸”(还在小班,歪歪扭扭地写了好多个),引得我哭笑不得。总的来说,过程中其实牺牲了很多陪伴家人的时间,基本上吃完晚饭就坐到电脑前开始码字了。然后,还有个有趣的事是他还跟着我知道了我插入的 Markdown 的 是SQL(感谢语雀优良的编辑器功能)。小小码农可能就是这样从小培养起来的吧。
现在来看那些写书的人,就知道家人得为作者付出多少了,真正的写那种厚厚的书,要占据相当多的时间,如果还需要上班的话,那在写书期间基本上是没有时间陪伴家人的。
翻译过程中最大的挑战其实是如何融会语言,尤其是一些专业术语转成中文有些时候挺别扭的,于是得上网找相关资料,以便更好地理解。再者就是例子了,有些原文的例子理解起来会比较容易,但需要自己去写 SQL 去验证。再有就是为了更好地理解,自己也会想一些例子补充,编写 SQL 来说明和验证。这个过程总的来说还是收获满满,对很多概念、机制都有了更深的理解,而且留下来不少文字,以后也能有机会“温故而知新”了。
结语
数据库和数据表的设计对于业务系统来说至关重要,是业务的根基。如果前期的设计出现问题,后期将导致效率、可维护性及其低下,最终得花很大的经理做重构和数据迁移,这对于线上运行很长时间的系统来说代价相当高。因此,掌握数据库和数据表设计的原则、理念和SQL 的机制十分重要。
另外对于程序员来说,最为难能可贵的职业素养之一就是回顾。去回顾自己写过的代码、设计过的数据表,然后再重新整理思路,优化和重构部分代码。这么一路下来收获会非常多,也能够看到过去自己的不足,和促进自己更进一步。近日的互联网的“躺平”说很火,但是对于程序员来说,“躺平”绝对是非常糟糕的一个行为。“996”、“007”固然让人有窒息的感觉,但是即便是没有“996”、“007”,也应该保持学习的动力和习惯。在程序员这个行业,始终是逆水行舟、不进则退的一个状态。千万不要等到自己发现远远落后于人的时候,再来一声悔不当初的叹息。