5、数据库设计中的反模式与解决方案

数据库设计中的反模式与解决方案

1. 无键入口反模式

1.1 问题引入

在数据库管理中，曾遇到两个经理为同一时间段预订了实验室的同一台服务器的问题。经检查发现，之前使用 MySQL 的 MyISAM 存储引擎设计的设备跟踪应用程序，由于该引擎不支持外键约束，导致数据库虽有逻辑关系但无法保证引用完整性。随着项目发展，数据操作方式增多，出现了报告数据不一致、小计不符以及日程重复预订等问题。

1.2 目标：简化数据库架构

关系数据库设计不仅关乎单个表，还涉及表与表之间的关系。引用完整性是数据库设计和操作的重要部分。声明外键约束时，这些列的值必须存在于父表的主键或唯一键列中。然而，部分软件开发人员建议避免使用引用完整性约束，原因如下：
- 数据更新可能与约束冲突。
- 使用的数据库设计过于灵活，无法支持外键约束。
- 认为数据库为外键创建的索引会影响性能。
- 使用不支持外键的数据库品牌。
- 需要查找声明外键的语法。

1.3 反模式：省略约束

乍一看，省略外键约束似乎能使数据库设计更简单、灵活或快速，但会带来其他问题，需要手动编写代码来确保引用完整性。

1.3.1 假设代码完美

许多人通过编写应用程序代码来确保数据关系始终满足引用完整性。插入行时，要确保外键列的值引用被引用表中的现有值；删除行时，要确保子表也得到适当更新。然而，在没有外键约束的情况下，为避免引用完整性错误，需在应用更改前运行额外的 SELECT 查询来确认更改不会导致引用断裂。例如：