9. 采用常用实体命名机构数据 组织数据的最简单办法就是采用常用名字，比如：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 等。采用一般抽象术语来标识“事物”的类别可以让你在关联数据以满足业务要求方面获得巨大的灵活性，同时这样做还可以显著降低数据存储所需的冗余量。
10. 用户来自世界各地 在设计用到网络或者具有其他国际特性的数据库时，一定要记住大多数国家都有不同的字段格式，比如邮政编码等，有些国家，比如新西兰就没有邮政编码一说
11. 数据重复需要采用分立的数据表 如果你发现自己在重复输入数据，请创建新表和新的关系。
12. 每个表中都应该添加的3 个有用的字段 · dRecordCreationDate，在VB 下默认是Now()，而在SQL Server 下默认为GETDATE()
· sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER
· nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因
13. 对地址和电话采用多个字段 描述街道地址就短短一行记录是不够的。ddress_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
过分标准化可要小心，这样做可能会导致性能上出现问。虽然地址和电话表分离通常可以达到最佳状态，但是如果需要经常访问这类信息，或许在其父表中存放“首选”信息（比如Customer 等）更为妥当些。非标准化和加速访问之间的妥协是有一定意义的。
14. 使用多个名称字段 我觉得很吃惊，许多人在数据库里就给 name 留一个字。我觉得只有刚入门的开发人员才会这么做，但实际上网上这种做法非常普遍。我建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候再把他们组合起来。要把这种情况变得对用户更为友好有好些方法。我最常用的是在同一表中创建一个计算列，通过它可以自动地连接标准化后的字段，这样数据变动的时候它也跟着变。不过，这样做在采用建模软件时得很机灵才行。总之，采用连接
字段的方式可以有效的隔离用户应用和开发人员界面。
15. 提防大小写混用的对象名和特殊字符 过去最令我恼火的事情之一就是数据库里有大小写混用的对象名，比如CustomerData。这一问题从Access 到Oracle 数据库都存在。我不喜欢采用这种大小写混用的对象命名方法，结果还不得不手工修改名字。想想看，这种数据库/应用程序能混到采用更强大数据库的那一天吗？采用全部大写而且包含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的
字符之间留空格。
16. 小心保留词 要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，最近我编写的一个ODBC 连接程序里有个表，其中就用了DESC 作为说明字段名。后果可想而知！DESC 是DESCENDING 缩写后的保留词。表里的一个SELECT *语句倒是能用，但我得到的却是一大堆毫无用处的信息。
17. 保持字段名和类型的一致性 在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在某个表中叫做“agreement_number”，你就别在另一个表里把名字改成“ref1”。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。记住，你干完自己的活了，其他人还要用你的数据库呢。
18. 仔细选择数字类型 在SQL 中使用smallint 和tinyint 类型要特别小心，比如，假如你想看看月销售总额，你的总额字段类型是smallint，那么，如果总额超过了$32,767 你就不能进行计算操作了。
19. 删除标记 在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
20. 避免使用触发器 触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
21. 包含版本机制 建议你在数据库中引入版本控制机制来确定使用中的数据库的版本。无论如何你都要实现这一要求。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。虽然你可以通过检查新字段或者索引来确定数据库结构的版本，但我发现把版本信息直接存放到数据库中不更为方便吗？。
22. 给文本字段留足余量 ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大，因为时间不长你多半就会因为要添加额外的字符而难堪不已。比方说，假设你的客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。这算浪费空间吗？是有一点，但也没你想象的那么多：一个字段加长3 个字符在有1 百万条记录，再加上一点索引的情况下才不过让整个数据库多占据3MB 的空间。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
23. 列命名技巧 我们发现，假如你给每个表的列名都采用统一的前缀，那么在编写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 Customer.surname = "MYNAME" and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第1 个SQL 语句没少键入多少字符。但如果查询涉及到5 个表乃至更多的列你就知道这个技巧多有用了。
