一、属性和联系的命名
数据库设计的一个期望的特性是唯一角色假设（unique-role assumption），这意味着每个属性名在数据库中只有唯一的含义。这使得我们不能使用同一个属性在不同的模型中表示不同的东西。虽然对不兼容的属性使用不同的名字是个好主意，但是如果不同关系中的属性有相同的含义，使用相同的名字可能是个好主意了。
尽管从技术上讲，一个模式中的属性名的顺序无关紧要，然而习惯上把主码（primary key）属性列在前面。这会使得查看默认输出（select * 的输出）更加容易。
不同的组织对于命名实体集有不同的习惯。举例来说，我们可能称一个学生的实体集为 student 或者 students。在数据库设计中我们采用了单数形式。使用单数或者复数形式都是可以接受的，只要所有实体都一致地使用该习惯就可以了。
随着模式变得更大，联系集的数量不断增加，使用对属性、联系和实体一致的命名会使得数据库设计者和应用程序员更加轻松。
二、为了性能去规范化
有时候数据库设计者会选择包含冗余信息的模式，也就是说，没有规范化。对一些特定的应用他们使用冗余来提高性能。不是用规范化模式的代价是用来保持冗余数据一致性的额外工作（以编码时间和执行时间计算）。
现今许多数据库支持一种更好的方法，即使用规范化的模式（回忆一下，物化视图是将结果存储在数据库中的视图，当它用到的关系更新时也相应更新。）像去规范化一样，使用物化视图确实会有空间和时间上的开销；不过它的也有优点，就是保持视图更新的工作是有数据库系统而不是应用程序员完成的。
三、时态数据建模
一般来说，时态数据（temporal data）是具有关联的时间段的数据，在时间段之间数据有效（valid）。我们使用数据的快照（snapshot）这个术语来表示一个特定时间点上 该数据的值。这样，course 数据的一张快照给出了在一个特定时间点上的所有课程的（诸如名称和系等）所有属性的值。
作为一个常见的特特例，如果所有对时态数据的参照都仅仅指向当前数据，更简单的解决办法是不在关系中添加时间信息，而是为过去的值创建一个相应的有时态信息的 history 关系。例如，在大学数据库中，我们可以使用已经创建的设计，忽略时态变化，仅仅存储当前信息。所有的历史信息都转移到历史关系中。这样，instructor 关系可以只存储当前地址，而关系 instructor_history 可以包含 instructor 所有的属性，以及额外的 start_time 和 end_time 属性。
四、总结
尽可能保持数据库表名、列名命名一致。当选择为了性能去规范化的时候，优先选择数据库系统内部的解决方案（视图），同样是空间换时间，把这个任务交给数据库系统能减少程序员的代码，并且从更底层解决问题有利于减少应用层的代码冗余，因为越接近底层就越容易锁定数据的单一出口。对于时态数据，建议将其保存到一个单独的实体集中，而不是修改原表。
