数据库设计在软件开发过程中占有重要的地位，国内开发者 MeteorSeed 在博客中结合自己的实际经历全面总结了关系型数据库设计需要注意的各个方面，包括 Codd 的基本法则、设计阶段、设计原则和命名规则。MeteorSeed 认为在项目早期应该由开发者进行数据库设计，后期调优则需要 DBA：“一个精通 OOP 和 ORM 的开发者，设计的数据库往往更为合理，更能适应需求的变化”。他引用了关系数据库之父 Codd 的 12 条法则，作为数据库设计的指导性方针：
信息法则
关系数据库中的所有信息都用唯一的一种方式表示——表中的值。
保证访问法则
依靠表名、主键值和列名的组合，保证能访问每个数据项。
空值的系统化处理
支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。
基于关系模型的动态联机目录
数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用户可以访问的表中。
统一的数据子语言法则
一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是 SQL)
视图更新法则
所有理论上可以更新的视图也可以由系统更新。
高级的插入、更新和删除操作
把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视作集合。
数据的物理独立性
不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都保持着逻辑上的不变性。
数据的逻辑独立性
当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑上的不变性。
数据完整性的独立性
专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定义，而且可以存储在数据目录中，而非程序中。
分布独立性
不管数据在物理是否分布式存储，或者任何时候改变分布策略，RDBMS 的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。
非破坏性法则
如果一个关系数据库系统支持某种低级（一次处理单个记录）语言，那么这个低级语言不能违反或绕过更高级语言（一次处理多个记录）规定的完整性法则或约束，即用户不能以任何方式违反数据库的约束。
MeteorSeed 把数据库设计阶段分为规划阶段、概念阶段、逻辑阶段、实现阶段和物理阶段。关于设计原则，他从以下几个方面阐述了自己的经验：
降低对数据库功能的依赖
功能应该由程序实现，而非 DB 实现。原因在于，如果功能由 DB 实现时，一旦更换的 DBMS 不如之前的系统强大，不能实现某些功能，这时我们将不得不去修改代码。所以，为了杜绝此类情况的发生，功能应该有程序实现，数据库仅仅负责数据的存储，以达到最低的耦合。
定义实体关系的原则
当定义一个实体与其他实体之间的关系时，需要考量如下：
牵涉到的实体 识别出关系所涉及的所有实体。
所有权 考虑一个实体“拥有”另一个实体的情况。
基数 考量一个实体的实例和另一个实体实例关联的数量。
关系与表数量
描述 1:1 关系最少需要 1 张表。
描述 1:n 关系最少需要 2 张表。
描述 n:n 关系最少需要 3 张表。
列意味着唯一的值
如果表示坐标（0,0），应该使用两列表示，而不是将“0,0”放在 1 个列中。
列的顺序
列的顺序对于表来说无关紧要，但是从习惯上来说，采用“主键 + 外键 + 实体数据 + 非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。
定义主键和外键
数据表必须定义主键和外键（如果有外键）。定义主键和外键不仅是 RDBMS 的要求，同时也是开发的要求。几乎所有的代码生成器都需要这些信息来生成常用方法的代码（包括 SQL 文和引用），所以，定义主键和外键在开发阶段是必须的。之所以说在开发阶段是必须的是因为，有不少团队出于性能考虑会在进行大量测试后，在保证参照完整性不会出现大的缺陷后，会删除掉 DB 的所有外键，以达到最优性能。MeteorSeed 认为，在性能没有出现问题时应该保留外键，而即便性能真的出现问题，也应该对 SQL 文进行优化，而非放弃外键约束。
参考：https://www.infoq.cn/article/2013%2F04%2Fdb-design-principle