文章插图
作为数据库设计人员，当我们负责数据库项目时，在数据库设计以及把数据库部署到生产环境的过程中可能会遇到一些挑战 。
其中一些问题不可避免，也无法控制 。但是，其中相当一部分可以追溯到数据库设计本身的质量 。我们在初步阶段所做的决定会对数据库最终的工作情况有深远的影响 。
糟糕的预规划如果我们要建一所房子，我们不会聘请一位工程承包商，然后马上就要求他们开始打地基 。这会导致灾难发生 。至少，我们需要就建房计划和蓝图达成一致 。数据库设计也一样 。我们规划得越好，设计的输出质量就越高 。
好的数据库是深思熟虑的结果，而不是临时想法的集合 。糟糕的设计规划会导致结构性问题，该数据库一旦推出后，要解决这些问题是相当昂贵的 。我们不可能总是能预测到数据库会遇到的所有问题，但是好的规划确保我们可以把问题减少到只有那些真正无法避免的问题 。
未能理解数据的用途创建数据库的目的相当广泛 。从存储个人私人信息的小型数据库到处理海量信息的大规模企业数据库 。设计人员必须明白数据库的目的所在，以便用最符合这些目标的方式来设计 。
要问的关键问题包括：数据的性质、数据获得的方式、数据存储和检索的频率、数据的规模、使用数据的应用程序是什么 。在工作日结束时手动输入数据的数据库和实时捕获并自动存储数据的复杂的行业数据库不能用同一种设计模型 。
设计的关键是确保数据效率、可用性和安全性的（请参考PostgreSQL 安全） 。忽略数据的目的将导致设计看上去符合所有的条条框框，但实际上是不健全的 。
规范化不足数据库设计不是一个严格确定的过程 。两个遵循同样设计规范的开发人员最终可以设计出两个截然不同的数据库 。这主要是因为任何软件工程项目都固有的创造性 。尽管如此，设计的一些核心原则对确保数据库以最佳方式运行至关重要 。其中之一就是规范化 。规范化指的是用于把表分解成组成部分的技术 。我们执行该操作，直到我们让每一张表只表示一种事物，而列描述该表所代表的项的属性 。规范化是一种古老的计算概念，已经有 30 多年的历史了 。事实上，SQL 主要用于读取和操作规范化数据集 。为了理解规范化，有必要了解 SQL 的工作原理 。
SQL 本质上是一种迭加式语言，适用于轻松创建结果集或值集 。使用 FROM 子句，我们可以从一张表中提取数据，并使用 JOIN 把数据添加到另一张表的内容中 。我们可以使用几乎无限数量的表来生成我们需要的数据 。SQL 的迭加能力对数据库开发和性能来说都至关重要 。
当索引与键值完全同步时，索引效果最佳 。当我们必须使用 LIKE、CHARINDEX、SUBSTRING 及类似命令来解析值与列值的组合时，SQL 范式遭到破坏，数据可搜索性变差 。
因此，规范化我们的数据库对简化开发和始终如一的高性能至关重要 。尽管如此，规范化还是有很多层次的，而且存在过度规范化的数据库 。良好的规范化平衡了记录插入、更新、查询和删除的需求 。采用最广泛的最佳实践是，数据库必须至少规范化到第三范式（Third Normal Form，简称 3NF） 。但是，第四（4NF）和第五（5NF）范式也相当有用，容易理解，也值得我们努力了解如何使用它们 。
冗余记录冗余表和字段对数据库设计人员和管理员来说是噩梦 。它们需要占用系统资源才能保持安全、更新和备份 。当我们讨论十多个记录时，冗余记录也许看起来不多 。但是，在大型数据库中，冗余字段可以是数千个或数百万个，计算资源开销很大 。它们不必要地增加了数据库的规模，降低了效率，增加了数据崩溃的风险 。
当然，有时候冗余也许是必要的，但是，这应该是例外，而不是规则 。即使允许冗余，也应当清楚地记录理由，以确保将来该理由不再有效时，数据库管理员可以删除冗余 。
糟糕的索引有时候，用户或应用程序可能需要查询一张表中的多个列 。随着表中行的数量的增长，用于完成这些查询的时间也在稳步增加 。为了加速查询并减少表规模的影响，谨慎的做法是索引表的列，以便在调用 SELECT 查询时，每个列中的条目几乎可以立即获得 。
不幸的是，加速 SELECT 函数通常会导致更常规的 INSERT、UPDATE 及 DELETE 命令的性能恶化 。这很大程度上是因为索引本身必须不断地与数据库的内容保持同步，而这又意味着大量的数据库引擎开销 。因此，具有讽刺意味的是，我们加速 SELECT 查询的尝试可能导致整个数据库变慢 。这是过度索引的经典案例 。
推荐阅读
- 架构：缓存设计
- SQL基础语法
- 快餐店设计装修风格有哪些
- 梅花五角|梅花五角中的梅花之王是谁？收藏价值大不大，现在价值多少？
- 服装店装修设计之招牌设计
- 烟酒店装修设计要点
- 奶茶店装修设计原则
- 火锅店设计装修的必备方案
- 宜红工夫茶属于六大茶类中的哪种 宜红工夫茶的制作工艺
- 解决并发问题，数据库常用的两把锁！