请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

搜索
热搜: 邮件服务器
查看: 634|回复: 2

【原创翻译】躲坑,数据库设计的九大常见错误(1)

[复制链接]
发表于 2020-8-24 14:10:31 | 显示全部楼层 |阅读模式

引言:本文向您介绍在数据库设计中常见的九种错误,希望能够帮你做躲开这些坑点的同时,构建出真正适合项目预期的数据库。
作为一名数据库设计人员,在您负责某个数据库项目时,难免会在初期设计的过程中,以及将数据库部署到生产环境之后,遇到不同的挑战。然而其中的一些很可能源自数据库的设计疏漏。也就是说,您在此初期所做出的某些决策,很可能会对数据库的最终运行情况产生深远的影响。因此,为了躲避这些坑点的出现,让我们来讨论一下数据库设计中常见的九大错误吧。
1. 不佳的规划
正如在盖房子时,您不可能要求建筑工人在一小时之内就铺设好地基那样,您需要事先规划好房屋的设计图纸。同理,您对数据库的初始设计和计划越周全,您的最终系统和服务的性能才会越好。
因此,一个具有前瞻性的数据库,绝不是由某些临时想法拼凑而成。不佳的设计很可能会导致数据库本身的结构性问题,而一旦它被部署到生产环境中,我们将面临着替换和调整成本高昂的窘境。虽然我们无法预料到数据库将来可能出现的每一个问题,但是良好的前期规划,确实能降低推倒重来的风险。
2. 未能理解数据的意图
无论是存储个人数据的小型数据库,还是处理复杂信息的大型企业级数据库,每一种类型的创建与使用往往是都是为了满足某个明确的数据意图。因此,设计人员只有真正理解了数据库的使用目的,才能根据这些目标进行最佳匹配模式的设计。
可见,他们需要问出的关键问题包括:数据的性质与类型、获取的方式、存储和检索的频率、数量、以及与之对应的各种应用程序。例如,那些需要在每日下班后手动录入信息的数据库,与能够将数据实时自动地捕获并存储的工业级复杂数据库相比,无论是在设计模型还是数据体量上,都是不一样的。
因此,设计的关键就在于确保数据处置的效率、可用性和安全性(请参见“PostgreSQL安全性”, https://www.datasunrise.com/datasunrise-for-postgresql/)。倘若盲目地追求数据库的大而全,反而是不切实际,而且不能够满足数据的具体应用需求。
3. 标准化不足
数据库设计并非是一个严格确定的过程。遵循相同设计规则的两位开发人员,往往不一定会设计出相同的数据布局。这主要取决于各种软件工程项目自身的创新性、和数据库在其中所扮演的作用。尽管如此,一些与设计有关的核心原则,还是能够对于确保数据库的最佳性能起到关键性作用的。而其中一项便是:规范化。数据的规范化特指:将数据表分解成为多个组成部分的技术。您可以持续进行此项操作,直到每一个数据表都只表示一种事物,而每一列都只代表该事物的某一项属性为止。
事实上,SQL主要就是建立在对于规范化数据集的读取和操作基础上的。您可以使用FROM子句从一个表中提取数据,并使用JOIN将其添加到另一个表的内容之中。您可以通过生成各种数据表来表示数据的类型。因此,SQL的附加功能对于数据库的开发和性能都是至关重要的。
索引通过与键值的完全同步,来增强其效果。当您必须使用LIKECHARINDEXSUBSTRING、以及类似的命令来解析某一列的组合值时,SQL语句通过分解,以减少数据被搜索的次数。
因此,规范化数据库对于简易开发和保持高性能都是至关重要的。我们可以根据不同的标准化水平,来满足数据库相关记录的插入、更新、查询和删除等需求。业界广为接受的最佳实践是:数据库必须至少达到第三范式(Normal Form3NF)的标准化水平。当然,第四(4NF)和第五(5NF)范式也是非常实用且易于理解的。
4. 多余的记录
多余的表和字段对于数据库设计人员和管理员来说简直是噩梦。它们消耗有限的系统资源,来保障系统整体的安全性、同步性和备份能力。特别是对于某些大型数据库来说,它们的冗余字段记录可能会达到几百万条,这对于计算资源的开销显然是相当庞大的。它们在增加数据库本身体积的同时,不但降低了系统的运行效率,而且提高了数据受损的潜在风险。
在此,我们并不是说数据记录的冗余没有必要,而是说:应当根据规则与策略,在做好相关记录的基础上实现数据的冗余,并且在超过保存期限和适用条件时,由数据库管理员及时予以删除或销毁。
5. 不佳索引
无论是用户还是应用程序,都可能会需要查询某个数据表的多个列值。然而,随着表中行记录的增加,相应的查询时间也会随之稳步上升。因此,为了加快查询的速度、并减少由表容量所产生的影响,我们需要通过对数据表的列进行索引,以便在调用SELECT查询时,表中的相对应记录条目能够实现“秒回”。
不过对于SELECT函数的加速,通常会导致有更多INSERTUPDATEDELETE命令的产生。这很大程度上是因为:索引本身就需要不断地与数据库的内容相同步,而此类操作就意味着会产生大量的数据库引擎开销。因此,颇具讽刺意味的是:您对加速SELECT查询的尝试,可能会反而导致数据库整体速度的变慢。这正是过度索引的经典案例。
解决上述问题的方法是:为所有列提供单一的索引,以用于查询表中的不同主键。您也可以按照从最常用到最少使用的不同列,进行降序排序。总之,构建索引是门技术活,需要您去花时间总结和调整。

  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-8-30 14:38:36 | 显示全部楼层
  谢谢分享
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-9-12 21:59:12 | 显示全部楼层
躲坑需要技巧。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 思科 CCO 登录 | 思科 CCO 注册   

本版积分规则

Archiver | 思科社区  

GMT+8, 2020-9-26 13:26 , Processed in 0.092710 second(s), 33 queries .

京ICP备11014401号-17

© 2020 思科系统.版权所有 重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表