开发人员如何有效的进行数据库设计

数据库设计在软件开发过程中占有重要的地位，国内开发者MeteorSeed在博客中结合自己的实际经历全面总结了关系型数据库设计需要注意的各个方面，包括Codd的基本法则、设计阶段、设计原则和命名规则。 MeteorSeed认为在项目早期应该由开发者进行数据库设计，后

数据库设计在软件开发过程中占有重要的地位，国内开发者MeteorSeed在博客中结合自己的实际经历全面总结了关系型数据库设计需要注意的各个方面，包括Codd的基本法则、设计阶段、设计原则和命名规则。

MeteorSeed认为在项目早期应该由开发者进行数据库设计，后期调优则需要DBA：“一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化”。他引用了关系数据库之父Codd的12条法则，作为数据库设计的指导性方针：

MeteorSeed把数据库设计阶段分为规划阶段、概念阶段、逻辑阶段、实现阶段和物理阶段。关于设计原则，他从以下几个方面阐述了自己的经验：

降低对数据库功能的依赖
功能应该由程序实现，香港虚拟主机，而非DB实现。原因在于，如果功能由DB实现时，一旦更换的DBMS不如之前的系统强大，不能实现某些功能，这时我们将不得不去修改代码。所以，香港空间，为了杜绝此类情况的发生，功能应该有程序实现，数据库仅仅负责数据的存储，以达到最低的耦合。

定义实体关系的原则
当定义一个实体与其他实体之间的关系时，需要考量如下：

关系与表数量

人工键与自然键。人工键——实体的非自然属性，根据需要由人强加的，如GUID，其对实体毫无意义；自然键——实体的自然属性，如身份证编号。人工键的好处：键值永远不变；永远是单列存储。人工键的缺点：因为人工键是没有实际意义的唯一值，所以不能通过人工键来避免重复行。MeteorSeed建议全部使用人工键。原因如下：

在设计阶段我们无法预测到代码真正需要的值，所以干脆放弃猜测键，服务器空间，而使用人工键。

人工键复杂处理实体关系，而不负责任何属性描述，这样的设计使得实体关系与实体内容得到高度解耦，这样做的设计思路更加清晰。

MeteorSeed的另一个建议是——每张表都需要有一个对用户而言有意义的自然键，在特殊情况下也许找不到这样一个项，此时可以使用复合键。这个键我在程序中并不会使用其作为唯一标识，但是却可以在对数据库直接进行查询时使用。使用人工键的另一个弊端，主要源自对查询性能的考量，因此选择人工键的形式（列的类型）很重要：

自增值类型，由于类型轻巧查询效率更好，但取值有限。

GUID查询效率不如值类型，但是取值无限，且对开发人员更加亲切。

智能健与非智能键。智能键——键值包含额外信息，其根据某种约定好的编码规范进行编码，从键值本身可以获取某些信息；非智能键，单纯的无意义键值，如自增的数字或GUID。智能键是一把双刃剑，开发人员偏爱这种包含信息的键值，程序盼望着其中潜在的数据；数据库管理员或者设计者则讨厌这种智能键，原因也是很显然的，智能键对数据库是潜在的风险。前面提到，数据库设计的原则之一是不要把具有独立意义的值的组合实现到一个单一的列中，应该使用多个独立的列。数据库设计者，更希望开发人员通过拼接多个列来得到智能键，即以复合主键的形式给开发人员使用，而不是将一个列的值分解后使用。开发人员应该接受这种数据库设计，但是很多开发者却想不明白两者的优略。MeteorSeed认为，使用单一列实现智能键存在这样一个风险，就是我们可能在设计阶段无法预期到编码规则可能会在后期发生变化。比如，构成智能键的局部键的值用完而引起规则变化或者长度变化，这种编码规则的变化对于程序的有效性验证与智能键解析是破坏性的，这是系统运维人员最不希望看到的。所以MeteorSeed建议如果需要智能键，请在业务逻辑层封装（使用只读属性），不要再持久化层实现，以避免上述问题。

除此之外，MeteorSeed还从“是否允许NULL”、属性切割、规范化（范式）、选择数据类型、优化并行等几个方面谈了设计原则。有关详细内容，可以查看MeteorSeed的博客原文。