数据库设计中的错误做法：你是否犯了这些错误？

本文概述

• 错误做法1：忽略数据的用途
• 错误做法2：标准化不佳
• 错误做法3：冗余
• 不良做法4：不良参照完整性(约束)
• 坏习惯5：不利用数据库引擎功能
• 错误做法6：复合主键
• 坏习惯7：索引编制不当
• 第8号不良做法：不良的命名约定
• 最后的一些评论

每当你作为开发人员被授予基于现有代码的任务时, 你都必须面对许多挑战。一个这样的挑战(通常不是最苛刻的挑战)涉及了解应用程序的数据模型。

通常, 你会遇到混乱的表, 视图, 列, 值, 存储过程, 函数, 约束和触发器, 这些过程需要很长时间才能使你理解。而且, 一旦这样做, 你就会开始注意到许多改善和利用存储的信息的方法。

如果你是一位经验丰富的开发人员, 你可能还会注意到一开始可能会做得更好的事情, 即设计缺陷。

在本文中, 你将了解一些常见的数据库设计错误做法, 它们为什么不好以及如何避免它们。

错误做法1：忽略数据的用途

数据被存储以供以后使用, 并且目标始终是以最有效的方式存储和检索数据。为此, 数据库设计人员必须事先知道数据将代表什么, 将如何获取数据, 以什么速率进行采集, 其操作量将是多少(即, 期望多少数据), 以及最后, 将如何使用它。

例如, 每天手动收集数据的工业信息系统将没有与实时生成信息的工业系统相同的数据模型。为什么？因为与同时管理数百万条记录相比, 每月处理数百或数千条记录有很大的不同。如果数据量很大, 设计人员必须特别考虑以保持数据库的效率和可用性。

但是, 当然, 数据量并不是唯一要考虑的方面, 因为数据的目的还会影响规范化级别, 数据结构, 记录大小以及整个系统的总体实现。

因此, 在完全了解将要创建的数据系统的用途的情况下, 需要考虑数据库引擎的选择, 要设计的实体, 记录大小和格式以及数据库引擎管理策略。

忽略这些目标将导致设计在基础上存在缺陷, 尽管在结构和数学上都是正确的。

错误做法2：标准化不佳

设计数据库不是确定性的任务。两位数据库设计人员可以针对给定问题遵循所有规则和规范化原则, 并且在大多数情况下, 他们将生成不同的数据布局。这是软件工程的创造性本质所固有的。但是, 有一些分析技术在每种情况下都有意义, 而遵循这些分析技术是获得性能最佳的数据库的最佳方法。

尽管如此, 我们经常会遇到在不遵循最基本规范化规则的情况下即时设计的数据库。我们必须清楚一点：每个数据库至少应规范化为第三范式, 因为这是最能代表你的实体的布局, 并且在查询和插入-更新-删除记录之间的性能将达到最佳平衡。

如果你发现不符合3NF, 2NF甚至1NF标准的表, 请考虑重新设计这些表。你投入的精力将在短期内得到回报。

错误做法3：冗余

与上一点非常相关, 因为归一化的目标之一是减少归一化, 所以冗余是另一种经常出现的不良做法。

冗余的字段和表对于开发人员来说是一场噩梦, 因为它们需要业务逻辑来使同一信息的许多版本保持最新。如果完全遵循规范化规则, 则可以避免这种开销。尽管有时冗余似乎是必要的, 但必须仅在非常特殊的情况下使用它, 并且必须清楚地记录下来, 以便在将来的开发中予以考虑。

冗余的典型不良影响是数据库大小不必要的增加, 数据容易出现不一致以及数据库效率降低, 但更重要的是, 这可能导致数据损坏。

不良做法4：不良参照完整性(约束)

参照完整性是数据库引擎提供的最有价值的工具之一, 可以使数据质量保持最佳状态。如果从设计阶段开始就没有约束或约束很少, 那么数据完整性将必须完全依赖于业务逻辑, 从而容易受到人为错误的影响。

坏习惯5：不利用数据库引擎功能

使用数据库引擎(DBE)时, 你将拥有功能强大的软件来执行数据处理任务, 这将简化软件开发并确保信息始终正确, 安全且可用。 DBE提供以下服务：

• 视图提供了一种快速有效的方式来查看数据, 通常出于查询目的对数据进行规范化而不会丢失数据的正确性。
• 有助于加快表查询速度的索引。
• 聚合功能, 无需编程即可帮助分析信息。
• 如果发生意外情况, 则全部执行并提交或取消(回滚)的事务或数据更改语句块, 从而使信息始终处于正确的状态。
• 在执行事务时可以保护数据安全和正确的锁。
• 存储过程提供编程功能以允许执行复杂的数据管理任务。
• 允许复杂计算和数据转换的功能。
• 有助于确保数据正确性并避免错误的约束。
• 当数据上发生事件时, 有助于自动执行操作的触发器。
• 在后台运行的命令优化器(执行计划程序), 确保每个语句都以最佳状态执行, 并保留执行计划以备将来之需。这是使用视图, 存储过程和函数的最佳理由之一, 因为它们的执行计划永久保存在DBE中。

不了解或忽略这些功能将使开发步入极其不确定的道路, 并且肯定会导致错误和将来的问题。

错误做法6：复合主键

这是一个有争议的观点, 因为当今许多数据库设计人员都在谈论使用整数ID自动生成的字段作为主键, 而不是使用由两个或多个字段的组合定义的复合键。目前, 这被定义为”最佳实践”, 就我个人而言, 我倾向于对此表示赞同。

但是, 这只是一个约定, 当然, DBE允许定义复合主键, 这是许多设计人员认为不可避免的。因此, 与冗余一样, 复合主键是设计决策。

但是请注意, 如果你的带有复合主键的表预计将具有数百万行, 那么控制复合键的索引可能会增长到CRUD操作性能大大下降的地步。在那种情况下, 最好使用一个简单的整数ID主键, 其索引将足够紧凑, 并建立必要的DBE约束以保持唯一性。

坏习惯7：索引编制不当

有时, 你将有一个需要按许多列查询的表。随着表的增长, 你会注意到这些列上的SELECT速度变慢。如果该表足够大, 那么从逻辑上讲, 你会考虑在用于访问该表的每一列上创建一个索引, 只是几乎立即发现SELECT的性能有所提高, 但INSERT, UPDATE和DELETE却下降了。当然, 这是由于必须将索引与表保持同步这一事实, 这意味着DBE的开销很大。这是过度索引的典型情况, 你可以通过多种方式解决该问题。例如, 与用于查询表的主键不同的是, 所有列上只有一个索引, 将这些列从使用最频繁到使用最少的顺序排列起来, 在所有CRUD操作中可能会提供比每列一个索引更好的性能。

另一方面, 众所周知, 表中没有用于查询的列的索引, 这将导致SELECTs的性能下降。

另外, 索引效率有时取决于列类型； INT列上的索引显示可能的最佳性能, 但是VARCHAR, DATE或DECIMAL上的索引(如果有意义)效率不高。这种考虑甚至可能导致重新设计需要以最佳效率访问的表。

因此, 索引编制始终是一个微妙的决定, 因为太多的索引可能太坏, 也可能太少, 并且因为要建立索引的列的数据类型对最终结果有很大的影响。

第8号不良做法：不良的命名约定

这是程序员在面对现有数据库时始终会遇到的难题：通过表和列的名称了解存储在其中的信息, 因为通常没有其他方法。

表名称必须描述其拥有的实体, 而每个列名称必须描述其代表的信息。这很容易, 但是当表必须相互关联时, 它开始变得复杂。名称开始变得混乱, 更糟的是, 如果将命名约定与不合逻辑的规范混淆(例如, “列名必须少于8个字符”)。最终结果是数据库变得不可读。

因此, 如果期望数据库能够持续运行并随其支持的应用程序一起发展, 则始终需要使用命名约定, 以下是一些准则, 以建立简洁, 简单且易读的数据库：

• 对表或列名称大小没有限制。具有描述性的名称比没有人记住或理解的首字母缩写更好。
• 相等的名称具有相同的含义。避免使用具有相同名称但具有不同类型或含义的字段；这迟早会令人困惑。
• 除非有必要, 否则不要多余。例如, 在”项目”表中, 无需具有”项目名称”, ” PriceOfItem”或类似名称之类的列； “名称”和”价格”就足够了。
• 提防DBE保留字。如果将一列称为”索引”(这是SQL保留字), 请尝试使用诸如” IndexNumber”之类的其他列。
• 如果坚持简单的主键规则(自动生成单个整数), 请在每个表中将其命名为” Id”。
• 如果要连接到另一个表, 则将必需的外键定义为一个名为” Id”的整数, 后跟连接表的名称(例如, IdItem)。
• 如果命名约束, 请使用描述约束的前缀(例如” PK”或” FK”), 后跟所涉及表的名称。当然, 少用下划线(_)可以使内容更具可读性。
• 要命名索引, 请使用前缀” IDX”, 后跟表名称和索引的一列或多列。另外, 如果索引是唯一的, 请使用” UNIQUE”作为前缀或后缀, 并在必要时加下划线。

互联网上有许多数据库命名准则, 它们将在数据库设计的这一非常重要的方面上提供更多的参考, 但是有了这些基本的准则, 你至少可以得到可读的数据库。这里重要的不是命名准则的大小或复杂性, 而是遵循准则的一致性！

最后的一些评论

数据库设计是知识和经验的结合；自成立之初, 软件行业就发展了很多。幸运的是, 有足够的知识可以帮助数据库设计人员获得最佳结果。

互联网上有良好的数据库设计指南, 还有数据库设计中应避免的不良做法和注意事项。只要选择并坚持下去。

而且, 请不要忘记, 你只能通过实验, 错误和成功来学习, 因此, 请立即开始。