2023年7月27日发(作者：)

数据库设计-设计表和字段1. 检查各种变化我在设计数据库的时候会考虑到哪些数据字段将来可能会发⽣变更。⽐⽅说，姓⽒就是如此（注

意是西⽅⼈的姓⽒，⽐如⼥性结婚后从夫姓等）。所以，在建⽴系统存储客户信息时，我倾向于

在单独的⼀个数据表⾥存储姓⽒字段，⽽且还附加起始⽇和终⽌⽇等字段，这样就可以跟踪这⼀

数据条⽬的变化。

— Shropshire Lad

2. 采⽤有意义的字段名

有⼀回我参加开发过⼀个项⽬，其中有从其他程序员那⾥继承的程序，那个程序员喜欢⽤屏幕上

显⽰数据指⽰⽤语命名字段，这也不赖，但不幸的是，她还喜欢⽤⼀些奇怪的命名法，其命名采

⽤了匈⽛利命名和控制序号的组合形式，⽐如cbo1、 txt2、txt2_b 等等。

除⾮你在使⽤只⾯向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些。当然，也别

做过头了，⽐如Customer_Shipping_Address_Street_Line_1 I 虽然很富有说明性，但没⼈愿意

键⼊这么长的名字，具体尺度就在你的把握中。

— Lamont Adams

3. 采⽤前缀命名

如果多个表⾥有好多同⼀类型的字段（⽐如FirstName），你不妨⽤特定表的前缀（⽐如

CusLastName）来帮助你标识字段。

— notoriousDOG

时效性数据应包括“最近更新⽇期/时间”字段。时间标记对查找数据问题的原因、按⽇期重新处

理/重载数据和清除旧数据特别有⽤。

— kol

5. 标准化和数据驱动

数据的标准化不仅⽅便了⾃⼰⽽且也⽅便了其他⼈。⽐⽅说，假如你的⽤户界⾯要访问外部数据

源（⽂件、XML ⽂档、其他数据库等），你不妨把相应的连接和路径信息存储在⽤户界⾯⽀持表

⾥。还有，如果⽤户界⾯执⾏⼯作流之类的任务（发送邮件、打印信笺、修改记录状态等），那

么产⽣⼯作流的数据也可以存放在数据库⾥。预先安排总需要付出努⼒，但如果这些过程采⽤数

据驱动⽽⾮硬编码的⽅式，那么策略变更和维护都会⽅便得多。事实上，如果过程是数据驱动

的，你就可以把相当⼤的责任推给⽤户，由⽤户来维护⾃⼰的⼯作流过程。

— tduvall

6. 标准化不能过头

对那些不熟悉标准化⼀词（normalization ）的⼈⽽⾔，标准化可以保证表内的字段都是最基础的

要素，⽽这⼀措施有助于消除数据库中的数据冗余。标准化有好⼏种形式，但Third Normal

Form（3NF）通常被认为在性能、扩展性和数据完整性⽅⾯达到了最好平衡。简单来说，3NF 规定：

· 表内的每⼀个值都只能被表达⼀次。

· 表内的每⼀⾏都应该被唯⼀的标识（有唯⼀键）。

· 表内不应该存储依赖于其他键的⾮键信息。

遵守3NF 标准的数据库具有以下特点：有⼀组表专门存放通过键连接起来的关联数据。⽐⽅说，

某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包

含定单关联客户的任何信息，但表内会存放⼀个键值，该键指向Customer 表⾥包含该客户信息

的那⼀⾏。

更⾼层次的标准化也有，但更标准是否就⼀定更好呢？答案是不⼀定。事实上，对某些项⽬来

说，甚⾄就连3NF 都可能给数据库引⼊太⾼的复杂性。

— Lamont Adams

为了效率的缘故，对表不进⾏标准化有时也是必要的，这样的例⼦很多。曾经有个开发财务分析

软件的活就是⽤⾮标准化表把查询时间从平均40 秒降低到了两秒左右。虽然我不得不这么做，

但我绝不把数据表的⾮标准化当作当然的设计理念。⽽具体的操作不过是⼀种派⽣。所以如果表

出了问题重新产⽣⾮标准化的表是完全可能的。

— epepke 7. Microsoft Access 报表技巧

如果你正在使⽤Microsoft Access，你可以⽤对⽤户友好的字段名来代替编号的名称：⽐如⽤

Customer Name 代替txtCNaM。这样，当你⽤向导程序创建表单和报表时，其名字会让那些不

是程序员的⼈更容易阅读。

— jwoodruf

8. 不活跃或者不采⽤的指⽰符

增加⼀个字段表⽰所在记录是否在业务中不再活跃挺有⽤的。不管是客户、员⼯还是其他什么

⼈，这样做都能有助于再运⾏查询的时候过滤活跃或者不活跃状态。同时还消除了新⽤户在采⽤

数据时所⾯临的⼀些问题，⽐如，某些记录可能不再为他们所⽤，再删除的时候可以起到⼀定 的

防范作⽤。

— theoden

9. 使⽤⾓⾊实体定义属于某类别的列

在需要对属于特定类别或者具有特定⾓⾊的事物做定义时，可以⽤⾓⾊实体来创建特定的时间关

联关系，从⽽可以实现⾃我⽂档化。

这⾥的含义不是让PERSON 实体带有Title 字段，⽽是说，为什么不⽤PERSON 实体和

PERSON_TYPE 实体来描述⼈员呢？然后，⽐⽅说，当 John Smith, Engineer 提升为John

Smith, Director 乃⾄最后爬到John Smith, CIO 的⾼位，⽽所有你要做的不过是改变两个表

PERSON 和PERSON_TYPE 之间关系的键值，同时增加⼀个⽇期/时间字段来知道变化是何时

发⽣的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，⽐如Associate、

Engineer、Director、CIO 或者CEO 等。

还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样⼀来在时间上⽆法跟踪

个⼈所处位置的具体时间。

— teburlew

10. 采⽤常⽤实体命名机构数据

组织数据的最简单办法就是采⽤常⽤名字，⽐如：PERSON、ORGANIZATION、ADDRESS 和

PHONE 等等。当你把这些常⽤的⼀般名字组合起来或者创建特定的相应副实体时，你就得到了

⾃⼰⽤的特殊版本。开始的时候采⽤⼀般术语的主要原因在于所有的具体⽤户都能对抽象事物具

体化。

有了这些抽象表⽰，你就可以在第2 级标识中采⽤⾃⼰的特殊名称，⽐如，PERSON 可能是

Employee、Spouse、Patient、Client、Customer、Vendor 或者Teacher 等。同样的，

ORGANIZATION 也可能是MyCompany、MyDepartment、Competitor、Hospital、

Warehouse、Government 等。最后ADDRESS 可以具体为Site、Location、Home、Work、

Client、Vendor、Corporate 和FieldOffice 等。

采⽤⼀般抽象术语来标识“事物”的类别可以让你在关联数据以满⾜业务要求⽅⾯获得巨⼤的灵

活性，同时这样做还可以显著降低数据存储所需的冗余量。

— teburlew

11. ⽤户来⾃世界各地

在设计⽤到⽹络或者具有其他国际特性的数据库时，⼀定要记住⼤多数国家都有不同的字段格

式，⽐如邮政编码等，有些国家，⽐如新西兰就没有邮政编码⼀说。

— billh

12. 数据重复需要采⽤分⽴的数据表

如果你发现⾃⼰在重复输⼊数据，请创建新表和新的关系。

— Alan Rash

13. 每个表中都应该添加的3 个有⽤的字段· dRecordCreationDate，在VB 下默认是Now()，⽽在SQL Server 下默认为GETDATE()

· sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER

· nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原

因

— Peter Ritchie

14. 对地址和电话采⽤多个字段 描述街道地址就短短⼀⾏记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可

以提供更⼤的灵活性。还有，电话号码和邮件地址最好拥有⾃⼰的数据表，其间具有⾃⾝的类型

和标记类别。

— dwnerd

过分标准化可要⼩⼼，这样做可能会导致性能上出现问题。虽然地址和电话表分离通常可以达到

最佳状态，但是如果需要经常访问这类信息，或许在其⽗表中存放“⾸选”信息（⽐如

Customer 等）更为妥当些。⾮标准化和加速访问之间的妥协是有⼀定意义的。

— dhattrem

15. 使⽤多个名称字段

我觉得很吃惊，许多⼈在数据库⾥就给 name 留⼀个字段。我觉得只有刚⼊门的开发⼈员才会这

么做，但实际上⽹上这种做法⾮常普遍。我建议应该把姓⽒和名字当作两个字段来处理，然后在

查询的时候再把他们组合起来。

— klempan

Klempan 不是唯⼀⼀个注意到使⽤单个name 字段的⼈，要把这种情况变得对⽤户更为友好有好

些⽅法。我最常⽤的是在同⼀表中创建⼀个计算列，通过它可以⾃动地连接标准化后的字段，这

样数据变动的时候它也跟着变。不过，这样做在采⽤建模软件时得很机灵才⾏。总之，采⽤连接

字段的⽅式可以有效的隔离⽤户应⽤和开发⼈员界⾯。

— damon

16. 提防⼤⼩写混⽤的对象名和特殊字符

过去最令我恼⽕的事情之⼀就是数据库⾥有⼤⼩写混⽤的对象名，⽐如CustomerData。这⼀问

题从Access 到Oracle 数据库都存在。我不喜欢采⽤这种⼤⼩写混⽤的对象命名⽅法，结果还不

得不⼿⼯修改名字。想想看，这种数据库/应⽤程序能混到采⽤更强⼤数据库的那⼀天吗？采⽤全

部⼤写⽽且包含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的

字符之间留空格。

— bfren

17. ⼩⼼保留词

要保证你的字段名没有和保留词、数据库系统或者常⽤访问⽅法冲突，⽐如，最近我编写的⼀个

ODBC 连接程序⾥有个表，其中就⽤了DESC 作为说明字段名。后果可想⽽知！DESC 是

DESCENDING 缩写后的保留词。表⾥的⼀个SELECT *语句倒是能⽤，但我得到的却是⼀⼤堆

毫⽆⽤处的信息。

— Daniel Jordan

18. 保持字段名和类型的⼀致性

在命名字段并为其指定数据类型的时候⼀定要保证⼀致性。假如字段在某个表中叫做

“agreement_number”，你就别在另⼀个表⾥把名字改成“ref1”。假如数据类型在⼀个表⾥

是整数，那在另⼀个表⾥可就别变成字符型了。记住，你⼲完⾃⼰的活了，其他⼈还要⽤你的数

据库呢。

— setanta

19. 仔细选择数字类型

在SQL 中使⽤smallint 和tinyint 类型要特别⼩⼼，⽐如，假如你想看看⽉销售总额，你的总额字

段类型是smallint，那么，如果总额超过了$32,767 你就不能进⾏计算操作了。

— egermain

20. 删除标记

在表中包含⼀个“删除标记”字段，这样就可以把⾏标记为删除。在关系数据库⾥不要单独删除

某⼀⾏；最好采⽤清除数据程序⽽且要仔细维护索引整体性。

— kol

21. 避免使⽤触发器

触发器的功能通常可以⽤其他⽅式实现。在调试程序时触发器可能成为⼲扰。假如你确实需要采

⽤触发器，你最好集中对它⽂档化。 — kol

22. 包含版本机制

建议你在数据库中引⼊版本控制机制来确定使⽤中的数据库的版本。⽆论如何你都要实现这⼀要

求。时间⼀长，⽤户的需求总是会改变的。最终可能会要求修改数据库结构。虽然你可以通过检

查新字段或者索引来确定数据库结构的版本，但我发现把版本信息直接存放到数据库中不更为⽅

便吗？。

— Richard Foster

23. 给⽂本字段留⾜余量ID 类型的⽂本字段，⽐如客户ID 或定单号等等都应该设置得⽐⼀般想象更⼤，因为时间不长你

多半就会因为要添加额外的字符⽽难堪不已。⽐⽅说，假设你的客户ID 为10 位数长。那你应该

把数据库表字段的长度设为12 或者13 个字符长。这算浪费空间吗？是有⼀点，但也没你想象的

那么多：⼀个字段加长3 个字符在有1 百万条记录，再加上⼀点索引的情况下才不过让整个数据

库多占据3MB 的空间。但这额外占据的空间却⽆需将来重构整个数据库就可以实现数据库规模

的增长了。

— tlundin

24. 列命名技巧

我们发现，假如你给每个表的列名都采⽤统⼀的前缀，那么在编写SQL 表达式的时候会得到⼤

⼤的简化。这样做也确实有缺点，⽐如破坏了⾃动表连接⼯具的作⽤，后者把公共列名同某些数

据库联系起来，不过就连这些⼯具有时不也连接错误嘛。举个简单的例⼦，假设有两个表：

Customer 和Order。Customer 表的前缀是cu_，所以该表内的⼦段名如下：cu_name_id、

cu_surname、cu_initials 和cu_address 等。Order 表的前缀是or_，所以⼦段名是：

or_order_id、or_cust_name_id、or_quantity 和or_description 等。

这样从数据库中选出全部数据的SQL 语句可以写成如下所⽰：

Select * from Customer, Order

Where cu_surname = "MYNAME"

and cu_name_id = or_cust_name_id

and or_quantity = 1;

在没有这些前缀的情况下则写成这个样⼦：

Select * from Customer, Order

Where e = "MYNAME"

and _id = _name_id

and ty = 1

第1 个SQL 语句没少键⼊多少字符。但如果查询涉及到5 个表乃⾄更多的列你就知道这个技巧

多有⽤了。

— Bryce Stenberg