关于数据表设计的若干原则

1.1      关键业务词汇的设计问题

1.     关键业务词汇会涉及到工程中很多地方如：解决方案名、项目名、模块及子模块目录、类文件、表格名、关键字段、实体类、变量命名、关联查询等诸多地方。所以定义好关键业务词汇表，是非常重要的事，它反应出我们对业务理解的程度以及对这种理解程度表达的准确度，是项目中具有决定性战略意义的重要一环。

2.     关键业务词汇，最好以一张表，以模块为中心来展现，并列出简称和全称，然后对团队成员进行讲解，解释为什么用这些词汇。而不是个人做列表就作为标准，这样有利于更加准确的表达业务词汇。关键词汇的确立，应该和有兴趣关心这方面问题的成员进行沟通，对不太关心这方面问题的成员，不宜沟通，以避免沟通流于形式。

1.2      数据表字段设计的建议

1.     对于关键性的字段最好冠以业务关键词的前缀，对什么样的字段要写前缀应慎重考虑。既要考虑不加前缀在表关联查询时引起混乱，又要避免滥加前缀让数据字段显得过于冗长。我个人认为，解决好字段命名，最关键是缩写取得比较优雅自然。一般来说对字段级的命名采用缩写，对类级及以上的关键业务词汇采用全称。

2.  对字段排列，建议尽量按如下顺序排列：

Ø  优先按业务逻辑排序

Ø  辅助性字段往后排

Ø  关联字段往后排列

Ø  总体观察排列是否自然，尽量调得比较自然

Ø  实体类的排列顺序尽量与数据表的排列保持相对一致

Ø  对于日期，布尔类型的字段尽量采用字符类型

 

1.3      从“编程”角度考量数据字段具有的重要特性

经过对编程过程的分析，我们认为对数据字段以下几个方面的特性要重点考量：

1.            决定表现控件的特性：

Ø    业务特性

Ø    数据类型

Ø    数据是输入还是选择

Ø    选择列表还应考虑其它几个特性：

a)            这个列表是固定的列表，还是可变列表？

b)           这个列表是简单的列表还是复杂列表，数据量有多大？

之所以从这些方面进行考虑，是因为编码时，一般情况下首先要进行界面布局，在布局的过程中要选取控件，而这与字段的业务特性、数据类型、是否选择都有一定关系，如果分析没有提供这些特性，在编程阶段必然要解决这些问题，由此而引起的资源开销相当大，而根据经验，我们认为这些特性在需求分析阶段完成更合适(注：这并不是说要由需求人员来做，可以让程序员参与这个阶段)。

2.            决定验证规则的特性：

Ø 是必输的，还是可输的

Ø 是否有输入限制：数字的范围、字符的格式等

Ø 是否需要复杂验证

这些特性，可以对数据输入的精确性产生一定的积极效果，但在实际运作过程中，我们可以在第一阶段完成后，再来补充完善这些规则，并完成相关的代码。不过，无论是管理人员，编程人员，还是测试人员，都应检查这些特性是否基本做到位？是否有不合适的地方？每个角色对这些特性进行检查完善，会比在制度上完全规定由某人来做合适。实际运作可以在第一阶段完成后，由程序员部分完成这些特性的定义，然后必须或者有必要与客户沟通的部分，再以“问题”的形式交由分析人员去与客户沟通。之所以这样做，我们认为负责与客户沟通的人员遇到突发性事件的机率比程序员要大，并且其工作任务难以变更，所以需要留出相当的机动时间，自行安排。而程序员的工作相对来说要求比较专一，不应太杂，他们的工作需要精细化，而这类事是程序员应该相对擅长的，与所做的模块属同一类事。同时，程序员的任务如果无法完成，将部分任务变更由另外的程序员来做相对容易一些。

3.            决定控件事件的特性

是否需要在控件产生事件时对外部提供回调。以及这些回调事件的相关业务意义是否值得这么做。