在创建一个数据库时，仅仅确定表和字段是不够的。数据需要以有序、安全且长期可管理的结构来保存。设计阶段所做的决策，随着系统的增长，要么构成一个坚实的基础，要么变成回过头来难以纠正的问题。数据库可谓是建立于其上的软件的地基；地基不牢，再好的软件也会随时间变慢、产生错误并变得难以维护。因此，数据库设计是软件开发一开始就需要审慎对待的课题。
防止数据的重复：normalization
好设计的根基在于同一信息不在多处被多余地重复。同一数据在不同表中被复制，既浪费存储空间，也在更新时制造不一致的风险：一份副本改了，另一份却仍是旧的。这种情况下哪条记录是正确的就变得模糊，对数据的信任也会受损。
Normalization（规范化）是把数据拆分为逻辑部分、并将每项信息只保存在一处的方法。例如，客户信息保存在一个单独的表中，而订单表只用一个引用与该客户相连。这样，当客户地址改变时，更新一条记录就足够了，而这一改动会自行反映到所有相关订单上。规范化能让数据保持有序；但它并不是在任何情况下都必须走到底的一条规则。在某些情况下，对于极其频繁被一起读取的数据，一种有节制的整合可以改善读取性能。重要的是，这一决策要有理有据、是有意识地做出的。
表与表之间的关系
表与表之间的正确关联，是维护数据库完整性的结构。关系把看似零散的表转化为一个有意义的整体，并确保数据保持一致。这些关联通过两个基本的键概念来建立。
Primary key（主键）：是唯一地标识一个表中每条记录的字段。它能防止同一记录被创建两次，以及各行相互混淆。每个表都被期望拥有一个能可靠地区分记录的 primary key。
Foreign key（外键）：使一个表中的记录能够连接到另一个表中的记录。例如，一条订单记录通过 foreign key 指向相关的客户记录。这种关系能防止诸如给一个不存在的客户录入订单，或误删一个仍有订单的客户之类的不一致情况。如此一来，数据库就能凭借自身的结构拒绝错误的操作。
选择合适的数据类型
为每个字段选择正确的数据类型，无论从存储效率还是从数据正确性来看都很重要。日期信息应以日期类型而非文本来保存，数值应以数字类型而非文本来保存。错误的类型选择会在日后的排序、计算和比较操作中导致意料之外的结果；例如当数字以文本形式保存时，”1004″ 可能会排在 “404” 之前，因为文本比较考量的是字符顺序而不是数值大小。
按需求确定字段长度和边界，也能防止多余的资源占用，并增加从一开始就录入错误数据的难度。在设计时就明确一个字段是否可留空、它可取的值范围及其格式，能长期把数据质量维持在高水平。从一开始就正确选定的类型，还能省去日后难做且有风险的转换。
index 与查询性能
随着数据量增加，快速找到所查记录变得至关重要。Index（索引）是为频繁被查询的字段创建、用以加速搜索的结构；它的工作方式类似一本书末尾的索引。没有索引，为找到所查记录可能需要扫描整个表；这会随表的增大而越来越慢。正确的 index 设计，能显著缩短在大表上运行的一条 query（查询）的响应时间。
然而使用 index 需要把握平衡。每个 index 在加速读取操作的同时，会给写入操作（插入、更新、删除）带来额外成本；因为记录改变时，相关的 index 也需要更新。此外，每个 index 都会消耗额外的存储空间。因此，index 不应随意设置，而应根据真正频繁使用的查询来规划。目标是在加速最常需要的查询的同时，不用多余的 index 负担拖累系统。
安全、授权与扩展
数据库设计不仅是结构问题，同时也是访问与持续性问题。以下几个方面从一开始就规划好，系统会更安全、更可持续：
- 用户授权：让每个用户只能访问其所需的数据，无论从安全还是从数据完整性来看都是必要的。通过角色来组织权限，能让管理更轻松。
- 定期备份（backup）：为在意外情况下能安全地找回数据，备份计划应从设计的最开始就作为其中一部分来考虑。
- 扩展预见：应考虑到今天看起来很小的一个表，随时间可能达到大量记录；结构应搭建成即便数据增大后仍可管理、有性能。
一个设计错误的数据库，会随着数据量增加而引发性能和管理问题，而事后消除这些问题多数时候既艰难又昂贵；因为结构一改变，依赖它的软件也需要更新。与之相反，一个设计正确的数据库，提供的是数据有序、关系一致、查询快速、访问安全的地基。简而言之，一套坚实的数据库设计，构成了建立于其上的软件更快速、更安全、更可持续运行的基础。
相关服务：数据库与数据管理、软件与 PC 应用、网页设计与软件
Leave a Reply