数据库设计心得-臭皮匠小队

组员心得体会：

邹智翼：

库连接起来的核心部分。我们小组的项目是智慧纪检：做一个用来审核审批的手机软件，实际上就是一个流水线式的任务处理应用，用于给用户来处理在web端发起的任务，需要在手机端显示任务流程内的所有内容和相关文件信息。

所以数据库需要存储各个任务流程的各种信息，尤其是各个任务的文件信息，文件信息采用存储文件url的方法，通过url从服务器获取文件，任务文件信息存储方式更加复杂一点，由于任务细分下去，总共有八大流程，每个流程内部还有小流程，所以编写了一个任务-大流程映射表和一个任务-小流程映射表，用于对应任务流程，同时，根据不同流程所需要的内容，编写表存储。在设计数据库的时候，我一开始就考虑任务和文件关系为1对多，使用任务编号和文件编号结合作为文件表的主键，但是再后来重新查看需求时发现，有时任务流程中可以下载一个模板文件，如果使用两个主键，不会映射到同一个模板文件中，所以再三考虑后，先将任务表内存储一个文件映射编号，然后再通过文件映射编号映射多个文件编号，再通过文件编号映射到文件表中的具体某个文件，这样就可以多个任务映射到一个文件。

这次数据库小组设计，在统筹上存在一些问题，导致汇总真和成一个表时十分麻烦。虽然提前开会商讨了数据库中表的命名方式以及各属性类型的选择，但是varchar的长度没有统一，并且部分内容没有按照统筹要求设置，导致后面必须修改统一。由于约束名字忘记提醒组员进行修改，各种外键的命名全是默认字符串，虽然没有影响，但是如果以后需要删除外键时，会非常麻烦，所以必须将其规范化，但是这本应该在汇总前就修改好的，统一修改极其耗时间。

部分数据库设计不满足范式要求，经过老师提出意见后进行了修改，由于任务中大部分的数据都是通过在前端进行选择填写的，所以说为此建立了很多的小表，用于存储选择的结果编号，然后使用一个映射表对应选择结果内容。

 

陈柏宇：

经过几周的慢慢摸索，我们最终也完成了一份数据库的设计。这个数据库的设计也是十分辛苦的，因为我们的项目是基于后端的开发，所以我们并没有机会跟真正的客户进行对接。导致我们只能根据学长们的创建的原型来进行提取信息，然后分类。这样得到的数据库信息是十分凌乱的，在web端的原型的很多页面可能是调用的同一个数据库表的内容。我们花费了大量的时间从web端一个界面一个界面的提取信息。我们对组每个成员负责原型中的一个流程，对其进行创表。其中，我负责的是线索管理这个部分。这个部分表的关系就特别复杂，因为它是刚开始创建信息部分，所以每一个表有许多的字段。在这里我就遇到了一个十分困惑的问题，对于每个表这么多字段怎么命名？有时候一个表中文名很长，而且用英文也不好翻译，在最开始，我采用的是用每个字开头的首字母。但是经过后来听老师讲课，我意识到一个问题，这样的命名有两个问题，第一可能字段名重复，大量的字段可能会是同一个发音，第二这样的命名到后期是很难看懂的，我们可能会忘记这个字段代表的是什么，导致很多新的麻烦。所以最后我还是采用的翻译的形式来进行命名，对每个字段名称的关键词进行翻译，然后连起来。在解决完这命名问题后，一个很关键的就是在一个信息中它由很多子表组成，最麻烦的到了三级的子表。每个子表的又有子表，这里卡了我很久。最后我采用的是将前一个表的主键作为后一个表的主键之一，这么一个一个连起来。最后最麻烦的就是将每个表单的字段进行分类。在这里其实我觉得我们组这一次创建数据库的方法并不是最优。我们是直接根据原型来创建的PDM，这就导致，我们要直接设计表与表之间的外键。这要求我们对项目的数据十分清晰，知道哪些数据可以放在一张表里面，才不会出现重复或多余的表。我个人认为，我们应该从CDM开始创建数据库，先找出每个具体的对象，通过设计对象，然后生成PDM，创建数据库。这样会使逻辑更清晰，创建的表更紧致，去掉冗杂。这次设计数据库的收获是非常丰富的。让我完成了从0到1的飞跃性变化。

 

洪绵权：

在这个项目中我们进行了数据库设计，对于从来没有过数据库设计经验的我来说，还没设计之前我以为只是简单的根据项目进行设计字段，可是真正的进入设计阶段才发现数据库设计没有想象中的那么简单，我们需要考虑到这个字段对应在实际项目中的哪个功能，有什么作用，与其他表中的字段有没有关联。就从最简单的命名都需要注意，我们需要保证命名的统一，不能造成二义性且不能晦涩难懂；然后就是数据类型，数据的长度，我们需要有预留空间，考虑到更多的其他情况； 然后就是数据库表的设计最后多写些注释，方便其他人，也方便开发人员本身在后续的开发中能够更快的了解数据库的结构，尤其是当数据库表很多时。还有就是需要理清每个表之间的关系，设置好相关的约束比如主键外键等，以方便维护。

其次，对于没有项目经验的我来说，可能还不是很笼统的了解数据库设计对于一个项目的重要性。首先对于一个项目来说，需要存储管理的数据量可能会非常大，因此我们首先需要进行数据库设计，一个良好的数据库设计可以节省数据的存储空间，并且能够保证数据的完整性，也方便进行数据库应用系统的开发，最重要的是方便我们对数据的管理及维护。而如果数据库设计比较糟糕，就会造成数据冗余、存储空间浪费，数据更新和插入的异常等一系列问题，因此数据库设计在项目开发中十分的重要。

最后，数据库设计的步骤也很重要，一般是有如下几个阶段:

需求分析阶段，概念结构设计阶段，逻辑结构设计阶段，物理结构设计阶段，数据库实施阶段及数据库的运行和维护阶段。遵循数据库的设计步骤能够帮助我们设计更合理且优良的数据库，但是我们这次好像并没有完全按照这些步骤进行数据库的设计，希望在以后能够继续完善。

 

雷佳晨：

这次的数据库设计，对我来说也是感悟、收获颇多的。由于我们的项目的特殊性，是app对接后台的，而后台和web端是学长的小组做的，所以说，我们没有机会真正的接触甲方，以至于我们项目的需求分析、各种数据的存储以及数据库的设计主要还是由我们自己分析的，然后根据自己分析到的需要存储的数据来进行数据库的设计，如果有不清楚的地方，主要是向学长他们进行询问。

这次数据库设计的时候，正如数据库实验的老师教我们的那样，设计数据库的人，要对最终的前端软件、产品做到“心里有数”：我的这个数据库设计完成后，它的前端产品该是什么样子的，该如何如何使用，有哪些细节问题等等，只有做到心中有前端产品，知道各种数据该如何存放，主键怎么设置，各个表之间有什么关系，各种数据都需要怎么样的表，大致需要多少张表来存放数据，有哪些数据需要存储，哪些数据又不需要存储，哪些数据怎么样存才能更加合理，怎么样存才能更好的满足我的业务需求，同时还要思考该如何让他们满足第一、二、三范式等、以及更高的要求，所以说，按我的理解来说，数据库的设计者，在设计数据库的过程中以及数据库设计完成之后，必然是已经对最终的前端产品有了一个详细的了解了，只有心里有了成品，才能设计出真正合理的数据库。

这次我们的数据库中，主要要存储的就是八个任务的发起流程的填表阶段，那些表中的数据很多，很杂乱，并且一长串的信息中，只能由一个任务编号作为它整张表的主键，很难再去具体的细分出其他的小表，所以说，从数据库的设计角度来说，这次我们的数据库设计显得很冗余，每张表存放的数据都很多，可能有三四十个字段，这在查找等操作时是很麻烦的，但按照我们数据库的实际应用来说，这些表的应用背景应该是多“写”少“读”少“修改”的，也就是说，一张存放发起流程表格信息的大表一般来说只进行一次写入，在写入完成后，是极少对其数据进行增删改的，所以说，这个数据库的发起表的设计，从普遍意义上来讲的确是很容易，很反常，但按照实际的应用背景来看，其实是没有太多的问题的。在这次数据库的设计的时候，我又再一次的感受到了团队的力量，正如老师说的那样，每个人的思考方式不一样，思考角度不一样，数据库的设计也是不一样的，每个人的数据库只要能正常使用，就算合理，但要有道理、要符合实际的应用。七八周设计数据库时，我们小组进行了很多次的线下讨论，每个人都来分析、介绍一下自己对各个流程的理解以及建表的具体想法，我们小组互相交流、讨论，最终整合意见、确定了一种最符合我们的前端实际使用的设计方法，而这些肯定是一个人设计数据库时所做不到的事情，所以团队在数据库的设计等方面起到的作用是无比重大的。

数据库的设计目前已经告一段落了，现在的任务是α迭代版本的完成了，加油吧！

 

梁耀升：

我们小组的项目是智慧纪检监察系统，对于这个系统，前面部分的线索管理涉及很多需要存储的信息，工程还是比较大。

相对于我们之前做过的项目，就比如结对编程，数据都是静态的，而现在做的项目，是前端要与数据库对接，来去获取，去展示这么一个动态数据，这是和以往的最大差别。

对于数据库设计之前，我们应该首先确定好设计的规范性。比如说数据类型的应确定好标准，由于前面需求文档，我们都对需求有了一定的了解，然后我们可以更好地去设计数据库，对于数据库，我们要分析出来有哪些实体，以及他们的属性，以及实体之间的关系，如何建立连接。

在这次数据库的设计与建立中，在学习的过程我们学到了很多，懂得也很多，在数据库设计方面我们选择使用power designer工具，通过构建CDM和PDM，然后将数据字典导出，将建表指令导出，可以省去很大一部分的工作量，同时，对于在构建PDM的过程中，我们也会对整个数据库的结构慢慢地渗入了解清晰。

在数据库的建立的时候，我们也遇到了一些问题，比如说数据冗余，重复的数据要尽量要少，一个属性不应该存在多个表中，如果出现这种情况，对于这个数据的更新或者检查的时候就会出现问题，如果数据发生变化的时候，都掉了某个表，那么就会导致数据存储就会不一致了。

在整个过程中我们学到了很多有用的技能，对数据库的有了更好的认知和理解，对于设计的过程中，需要合理的分工和协作，扬长避短可以很好地提高大家的积极性，同时对于设计表的时候，需要多听取其他人的意见，不能固执己见。

 

小组总结：

在这次数据库设计中，由于我们组的项目是一个任务处理型项目，需要建立很多个表，所以建表的任务就按任务流程分配给了各个组员。由于各个任务表的设计分开了，所以需要我们进行统筹规划，避免整合时出现太多问题。在整合规划上，组内认为的难题有：表内属性如何命名、表内属性如何规范化设置，而解决改问题的方法就是多交流，然后定下一个命名规范和数据类型规范，但是实际操作上，我们组设置了属性的命名规范和数据类型规范，但是忘了让组员重命名约束名，使得整合时的时间消耗更大。设计数据库时，组内的交流、分工、协作必不可少，只有多加交流，了解各组员的设计思路、想法，才可以减少在整合阶段出现的矛盾冲突。