第74节

作者:tangtdd | TXT小说下载 | 返回目录:74章/108章 | 上一节 | 下一节

日期：2011-09-10　01:35:58
      
      　　（四十一）卑微的角色
      　　研发部中的其他三位同事，搞硬件的其中一位同事，姓钟，一般被大家称为小钟，其年龄与我相仿，长得有几分英俊，人有几分风趣和潇洒。搞硬件的另一位同事，单名一个良字，一般被立经理昵称为良子。良子比我小三岁，个子不算高，脸圆圆的，有点娃娃脸的感觉，虽然其心智很成熟，但从其脸上似乎看不出他经历过很多的事情。另一位做机箱结构设计的同事，姓林，部门里外的同事一致称其为林工。林工比我小两岁，个子也不算高，微胖，人有点直爽，说话声音很大，很能侃，人缘也似乎很好。良子和林工虽然来自同一个省份安徽省，但两人在性情和行为方式上却有着很大的不同，在林工身上很容易就找到北方人的影子，但良子却似乎更偏向于南方人的内敛。
      
      　　小钟是广东人，已在广州的远郊买房并结婚生子，而且他和宗一样，是有有车一族，虽然都不是很贵的车，但毕竟已跻身有车人士的行列了。大概正因为小钟各方面都比较稳定了，没有了这个年龄阶段的各种压力，所以人就比较潇洒。
      　　我将有关资料整理后，便真正开始做需要分析了。按照我自己的工作习惯，做需求分析的过程中，第一步要做的工作就是设计数据库，根据实际业务情况建立数据库的表。数据库是一个系统的根基，只有先将根基打好了，才能去做程序架构的搭建、网页的设计和制作、程序的编写等其他的工作（当然数据库的设计和程序架构的搭建可以同时进行）。
      　　视频管理系统采用的数据库自然就是我所熟悉的SQLServer2000，而不是MySQL。就在我准备设计数据库的时候，宗跟我说，我做需求分析，要先将数据库设计的情况等用DOC文档写下来。于是我跟他说，我想先在SQLServer2000中将数据库建好后，再用DOC文档将有关情况写下来。但宗却说，不行，要先用DOC文档写下来。于是我再跟他说，因为我习惯了先在SQLServer2000中建数据库，我建好数据库后再写也一样。但宗却大手一挥说，“现在就是要你这样做，先用DOC文档写下来！我们不会看你在SQLServer2000中的设计，我们要的是文档！”
      
      　　宗的语气很坚决，态度很强硬，毫无商量的余地，于是我便不好再跟他多说什么，只好有点勉强地一边点头一边说，“好好，那我就先写DOC文档！”
      　　这些对话都是当着部门中各人的面进行的，虽然不算很激烈，但宗的语气并不友好，态度强硬，中间我的语气也提高了，所以整个对话过程已或多或少地隐含着矛盾。
      　　在公司里，服从上司的命令是没错，但在不影响工作开展和实际结果的前提下，我觉得上司也应该尊重一下下属的工作方式和工作习惯。我之所以想先在SQLServer2000中建数据库，是因为在SQLServer2000中进行实际的建表操作可以做到所见即所得，如果先写DOC文档，难免会“纸上谈兵”，有时还是要借助SQLServer2000来解决一些实际的问题，所以我才有这样的想法，这也是我在以往工作中所形成的习惯。但宗却没有给我一点这样的自由度，所以虽然表面上我服从了他的命令，但在心里我对他还是有些抗拒。我心中的芥蒂也由此埋下。
      
      　　虽然心里不情愿，但我还是按照宗的要求，在做需求分析的时候先写DOC文档。这其实主要就是将在SQLServer2000中要建的表在DOC文档中用表格的形式表示出来，包括表的列名（字段名）、数据类型、说明（字段说明）、备注等信息，实际上就等于是在DOC文档中“建表”，只不过以后还要照着这个信息在SQLServer2000中再进行一次真正的建表操作。
      　　虽然是在DOC文档中“建表”，但这其实就是在做需求分析，这也是真实建表的反映，所以其信息也必须准确，因此我还是不能有半点马虎，否则如果其信息不准确，到真正建表后，系统的根基就会有问题。因此这就是一项重要的工作。
      　　经过对祝老师所讲解到的内容和他发给我的那个DOC文档以及我整理出来的资料进行分析，去繁取简，去伪存真，并经过多日的脑力激荡后，在DOC文档中“建表”的工作也渐渐完成。此时的我已不是当年的吴下阿蒙，凭着我在网站程序开发和数据库设计方面所积累起来的经验，我还是顺利地完成了这个很重要的需求分析的过程，将那些繁杂的需求用数据库的表初步地表现出来了。不但顺利地完成了，而且我自认为这个需求分析还做得相对准确，我能将那些繁杂的需求用程序的元素相对准确的表现出来。而表的命名、字段的命名等都按规范来做，自不在话下。
      
      　　这项工作可以说是有别于以往的工作，虽然没开始前对我来说是一个挑战，但经过这个过程后，我却更能从总体上去分析和把握一个系统的最底层的结构，将繁杂的需求变成系统和程序开发所需要的元素。这对我来说却未必不是一件好事。
      　　我认为一个系统，最初的数据库设计很重要（在这里特指表的设计），这无关乎后面的程序用什么语言去开发，也无关乎语言版本的新旧，数据库设计得好与不好，将成为一个系统是否能成为好系统的先决条件。任你用再牛的语言，用再新的语言版本，你的程序算法再牛，但如果你的数据库设计得不准确，不符合实际业务情况和实际业务逻辑，那么你开发出来的系统也只能是一个不合格的系统。而这一点此时我认为我做到了。
      
      　　文档写好后，我便将其交给宗过目，征求其意见。宗看后提出，表的主键不能用uniqueidentifier数据类型（GUID，全局唯一标识符），就用属性为IDENTITY的int数据类型，以方便日后数据库可以由SQLServer2000迁移到MySQL或其他类型的数据库。
      　　我之所以用uniqueidentifier数据类型，是因为在邮购公司时，兑换系统数据库的表的主键都是用uniqueidentifier数据类型的，我从中借鉴过来。表的主键用uniqueidentifier数据类型的好处是不能猜到主键的值，这对于商用系统很有好处，可以防止猜主键值（即防止猜ID），当然还有其他好处；不好之处是uniqueidentifier数据类型在实际应用中处理起来会比较麻烦，而且占用存储空间相对大一些，可能影响到程序执行的效率。本来我是从商用和安全的角度去考虑的，但既然宗这么提出来了，我也不想搞得那么复杂，于是去繁从简，表的主健全改为用属性为IDENTITY的int数据类型，IDENTITY的种子值和增量值自然就均设为1了（初始值为1，并自增1）。
      
      　　改完后再给宗看，宗说我还要将各表所代表的各部分主要功能用流程图的形式画出来。虽然表是设计出来了，但对于系统的功能要怎么更好地呈现出来，我也不可能一下子就有一个清晰的概念，我认为这需要在正式编写程序的过程中逐步去完成构思，最重要的是，表设计出来了，系统的功能就可以按照这个最底层的结构去展开。我这样跟宗解释后，问他能不能不画这样的流程图，但他还是要我先将这样的流程图画出来。
      
      　　也许从正规化开发的角度去看，宗的要求没错，但是你不能跟我说正规化，这只是小作坊的开发而已，没必要上升到正规化的高度，你让我都按正规化来，那正规化本身所用的时间，我可能已可以将系统开发出来了。更何况我在文档中“建”的表，都是用具有实际意义的英文表名和字段名，并配上中文说明和备注，表的外键和关联表的主键的字段名均相同，各表的关系已清清楚楚，只要是做这方面工作的人都能看得明白，无需再多作说明。
      
      　　但是我不能跟宗说这些，我还是要画所谓的流程图。但是我实在不善于画这样的流程图，无法按宗所要求的画出来，所以只将模拟程序执行时各表可能访问到的先后顺序用方图的形式画出来，并将各个表的用途和作用用文字简要地描述出来。
      　　宗看后说，这都不是他想要的样子，我说我只能做到这样了，他也只好说那就算了，就这样吧。我不明白，你为什么一定要我做这些形式上的东西呢？我最终能将系统开发出来不就行了吗？