前期工作一：定义标准的对象命名规范。
一定要定义数据库对象的命名规范，这是笔者一再坚持的一个观点。在开发数据库项目之前，项目开发团队要先讨论确定数据库对象的命名规范。包括函数、过程、表、视图、字段等的命名规则。因为我们在数据库开发过程中会重复的引用这些对象。若没有一个统一的命名规则，只有对象的所有者知道其所代表的含义。那么其他数据库开发人员想引用某个对象的时候，就会茫然不知道从何下手。所以，制定一个统一的数据库对象命名规范，这是数据库设计的一个必要的前期准备工作。
1、利用前缀区分各个对象。在Oracle数据库中，基本的对象有函数、过程、表、视图等等。对于表以外的对象，笔者建议通过前缀来对他们进行区分。如函数名就用FUN前缀，视图就用View前缀等等。如此，当在其他对象中调用视图或者函数的时候，就可以通过输入View前缀，让数据库系统只列出数据库当前的所有视图对象。通过这种方法，就是缩小我们选择的范围，提高对象引用的效率。
2、可以根据不同的功能模块来对基础表进行命名。如对于ERP来说，光基础表就有上千张。这么多的表如何进行有序的管理?笔者建议，可以按软件功能模块的简称作为其前缀。如对于财务模块用到的基础表，可以利用FI前缀;销售模块涉及到的基础表则采用SA前缀。通过这种命名规则，一看到前缀就可以联想到表的用途。无疑，这可以提高表命名的可读性;也方便数据库开发人员对表对象的引用。
3、对于字段来说，命名规范所涉及到的技巧更加多了。如笔者常常会在一些字段的后面加入一个后缀，表示这个字段所对应的数据类型。如订单数量是一个典型的数字类型字段，则笔者会在后面加入NUM后缀。这么处理后，当他们要在其他对象中引用这个字段的时候，就不用费心的去想、去找资料，确定这个字段的数据类型了。如在设置字段列名的时候，笔者喜欢把表的前缀加入到字段名中。如现在销售订单中有个销售订单ID的字段，笔者把它命名为Or_Order_ID;在出货单上，也需要用到这个字段，笔者命名为OU_Order_ID。当我们在做定单出货明细表的时候，引用这两个字段时，就不需要在前面输入具体的表名。若我们把加入表的前缀，两张表中的字段都命名为Order_ID，则在引用他们的时候，被参考的表的ID字段要加入表名。若其关联查询的表越多，则每一张表都要加入表名才能够对其进行引用。很明显，前者的引用方式要节省工作量。
当然，上述的命名规范要根据自己的项目团队的爱好来定。总之一个基本的原则，就是命名规范要统一。不能够一个开发团队三个开发人员一人一套，这不利于项目团队之间的合作。
前期工作二：考虑系统的灵活性。
一个优秀的数据库管理员，在数据库开发的时候，往往会考虑用户未来的需求变化，以提高数据库的灵活性。若用户每次变更一下需求，都要通过变更数据库对象来实现，那这个数据库也太过于僵硬了。
故笔者认为，数据库管理员在对数据库开发之前，要跟客户进行沟通。确定在未来哪些方面可能会发生变更，然后采取某些策略，对其进行控制。力保在不对数据库进行调整的情况下，通过一些简单的配置，实现对需求的调整。
如笔者一次在开发一个超市零售系统数据库的时候，笔者在跟客户的沟通中，就遇到了这么一个细节问题。超市产品的价格可能会有一些季节性的调价问题。按照以前的设计，系统只能够实现有规律的条件，如某类产品统一上挑多少个百分点等等。但是，这远远不能够满足企业的需求。因为在调整价格之前，他们都会通过Excle表格的形式，跟供应商确认条件的事情。所以，超市管理员希望能够直接根据这份表格对系统中的价格进行更新。笔者了解这个信息后，就涉及了一个价格更新的批处理程序，方便用户对价格进行成批的更新。
这些功能不要看其小，但是，却可以给客户一种很好的感觉。说实话，现在同类系统之间的抄袭现象已经很严重，同质化现象越来越突出。我们只有在用户友好性与系统灵活性上下功夫，才能够拉拢客户，引得比较好的知名度。