前期工作一：定义标准的对象命名规范。

    一定要定义数据库对象的命名规范，这是笔者一再坚持的一个观点。在开发数据库项目之前，项目开发团队要先讨论确定数据库对象的命名规范。包括函数、过程、表、视图、字段等的命名规则。因为我们在数据库开发过程中会重复的引用这些对象。若没有一个统一的命名规则，只有对象的所有者知道其所代表的含义。那么其他数据库开发人员想引用某个对象的时候，就会茫然不知道从何下手。所以，制定一个统一的数据库对象命名规范，这是数据库设计的一个必要的前期准备工作。

    1、利用前缀区分各个对象。在Oracle数据库中，基本的对象有函数、过程、表、视图等等。对于表以外的对象，笔者建议通过前缀来对他们进行区分。如函数名就用FUN前缀，视图就用View前缀等等。如此，当在其他对象中调用视图或者函数的时候，就可以通过输入View前缀，让数据库系统只列出数据库当前的所有视图对象。通过这种方法，就是缩小我们选择的范围，提高对象引用的效率。

    2、可以根据不同的功能模块来对基础表进行命名。如对于ERP来说，光基础表就有上千张。这么多的表如何进行有序的管理？笔者建议，可以按软件功能模块的简称作为其前缀。如对于财务模块用到的基础表，可以利用FI前缀；销售模块涉及到的基础表则采用SA前缀。通过这种命名规则，一看到前缀就可以联想到表的用途。无疑，这可以提高表命名的可读性；也方便数据库开发人员对表对象的引用。

    3、对于字段来说，命名规范所涉及到的技巧更加多了。如笔者常常会在一些字段的后面加入一个后缀，表示这个字段所对应的数据类型。如订单数量是一个典型的数字类型字段，则笔者会在后面加入NUM后缀。这么处理后，当他们要在其他对象中引用这个字段的时候，就不用费心的去想、去找资料，确定这个字段的数据类型了。如在设置字段列名的时候，笔者喜欢把表的前缀加入到字段名中。如现在销售订单中有个销售订单ID的字段，笔者把它命名为Or_Order_ID;在出货单上，也需要用到这个字段，笔者命名为OU_Order_ID。当我们在做定单出货明细表的时候，引用这两个字段时，就不需要在前面输入具体的表名。若我们把加入表的前缀，两张表中的字段都命名为Order_ID，则在引用他们的时候，被参考的表的ID字段要加入表名。若其关联查询的表越多，则每一张表都要加入表名才能够对其进行引用。很明显，前者的引用方式要节省工作量。

    当然，上述的命名规范要根据自己的项目团队的爱好来定。总之一个基本的原则，就是命名规范要统一。不能够一个开发团队三个开发人员一人一套，这不利于项目团队之间的合作。

    前期工作二：考虑系统的灵活性。

    一个优秀的数据库管理员，在数据库开发的时候，往往会考虑用户未来的需求变化，以提高数据库的灵活性。若用户每次变更一下需求，都要通过变更数据库对象来实现，那这个数据库也太过于僵硬了。

    故笔者认为，数据库管理员在对数据库开发之前，要跟客户进行沟通。确定在未来哪些方面可能会发生变更，然后采取某些策略，对其进行控制。力保在不对数据库进行调整的情况下，通过一些简单的配置，实现对需求的调整。

    如笔者一次在开发一个超市零售系统数据库的时候，笔者在跟客户的沟通中，就遇到了这么一个细节问题。超市产品的价格可能会有一些季节性的调价问题。按照以前的设计，系统只能够实现有规律的条件，如某类产品统一上挑多少个百分点等等。但是，这远远不能够满足企业的需求。因为在调整价格之前，他们都会通过Excle表格的形式，跟供应商确认条件的事情。所以，超市管理员希望能够直接根据这份表格对系统中的价格进行更新。笔者了解这个信息后，就涉及了一个价格更新的批处理程序，方便用户对价格进行成批的更新。

    这些功能不要看其小，但是，却可以给客户一种很好的感觉。说实话，现在同类系统之间的抄袭现象已经很严重，同质化现象越来越突出。我们只有在用户友好性与系统灵活性上下功夫，才能够拉拢客户，引得比较好的知名度。

    前期工作三：充分重视报表的设计工作。

    用户在使用系统的时候，做多用到的功能是什么呢？不是数据的更新，而是查询。而查询中，80%以上都是通过报表功能来实现的。所以，从数据库对象的角度来考虑，用户用到的最多的就是报表。同时，因为报表需要对多张表实现关联查询，而且，其包含的记录又比较多。所以，其设计的好坏，又直接关系到数据库的性能。

    在对报表进行设计的时候，除了要充分考虑用户的需求之外，还需要考虑如下几个关键问题。

    一是记录的排序问题。在报表设计的时候，我们希望能够实现，报表一生成，其记录排序就符合用户的常规需要，而不需要用户再进行调整。如有一张库存交易记录报表，在排序的时候，可以按产品来进行排序，也可以按交易日期来排序，又可以根据单据类型来排序。此时，数据库开发人员就需要跟客户进行沟通，看看其喜爱的排序方式是什么。当从数据库查询出数据，然后用户再对其重新排序的时候，若记录比较多的话，则其仍然需要几十秒不等的等待时间。故合理设置报表纪录的排序问题，是数据库报表设计之前首先要跟客户确认的问题。

    二是在报表中要尽量避免采用系统主键。由系统产生的主键在报表中很难管理。如当用户在具有系统生成主键的表内用副键进行查找往往会返回多条重复记录。所以，在报表中采用系统主键来进行检索，不但效率低，而且容易引起数据查询的混乱。故在报表设计的时候，宁可利用用户主键，也不要采用系统主键。

    三是数据汇总尽量通过前台程序实现。有时候，用户往往需要对报表中的记录进行汇总。如销售订单总的销售金额、当前的出货累计金额等等。这些汇总的功能即可以在报表视图中实现，也可以通过前台程序控制。笔者比较倾向与后者。因为在数据库设计的时候，即使数据库管理员跟客户进行了充分的沟通，也难保其后续需求的变化。为了提高数据库的灵活性，最好能够在前台实现报表自定义功能。让用户根据自身的需求，在前台对相关汇总选项进行控制。此时，就需要数据库管理员跟前台程序开发人员进行协商，确定相关的参数。

    前期工作四：做好ER图表与数字字典的维护工作。

    在数据库开发项目之前，项目团队还是有必要做一份ER图表，并且建立数字字典。确实，要做好这两件工作，会花费比较多的时间与精力。但是，若你数据库开发项目是一个团队，而不是单枪匹马的话，则就会起到很大的作用。

    ER图表与数字字典有利于帮助其他开发人员了解数据库的整个设计思路。在数据库设计之间做好ER图表以及数字字典，可以有效的避免今后可能面临的管理混乱问题。而且数字字典中包换每个字段的数据类型；ER图表中包含每个表的主外键。这就方便了项目团队成员对其他人建立的对象的引用。

    若做个形象的比喻，ER图表就好像是写作文的提纲。一个提纲列的好坏，直接跟文章的质量有关。建立了ER图表之后，作为项目负责人，就可以给各个项目成员分配工作。有利于项目管理员协调各个项目成员的工作。

    故笔者认为，在数据库项目正式开始之前，项目团队花些时间，做好ER图表以及数据字典的相关工作，这是必须的。虽然需要耗费比较长的时间，可是这个投资到时候肯定会有回报。

    以上四个前期准备工作，是笔者在数据库开发之前必需要完成的准备工作。只要有一项没有完成，笔者就会觉得还有什么东西忘了似的，不敢贸然进行数据库的开发。笔者在这里强烈建议，在数据库开发之前，认真做好这四项基本的准备工作。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。