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

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

搜索
热搜: 邮件服务器
查看: 550|回复: 3

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

[复制链接]
发表于 2020-8-28 17:09:22 | 显示全部楼层 |阅读模式
6. 所有域值的单一表
包罗万象的域表(domain table)并非是数据库设计的最佳方法。记住,关系型数据库的构建理念是:数据库中的每个对象都只代表一个事物,不可出现任何指代不清的数据集。通过导航主键、表名、列名、以及各种关系,应用能够快速地解读出数据集的含义。尽管如此,在进行数据库设计时,许多人总会情不自禁地滑向:数据表越来越多,数据库越来越复杂和混乱的深渊。
过去,业界的普遍做法是将多张表压缩到一张表之中,进而简化设计。但是这往往会带来效率低下、且难以操作等问题。而且SQL代码会随着变长,可读性也会有所下降。可见单一域表貌似一个抽象的文本容器,但它的确不是数据库设计的最佳方式。
那么,作为规范化的一部分,我们需要通过数据隔离和分解的方法,让每一行都只代表一个事物,同时让多个域表相互区别不同的事物。其好处在于:
u  让数据的查询更加容易。
u  使用外键约束来更自然地验证数据,而这正式单域表设计所无法实现的。因为在单域表中,每张表所需的各种键会变得难以维护。
u  每当您想为某个对象添加多种数据时,您只需简单地增加一到多列便可。
u  小型域表(small-domain tables)适合于存储在硬盘的单页上,而大型域表很可能会扩展到多个磁盘的多个扇区里。显然,将表存放在单页中就意味着我们可以通过对单个磁盘的读取,以快速提取数据。
u  因为这些域表很可能具有相同的底层用法与结构,因此拥有多个域表并不会妨碍您为所有的行启用同一编辑器。
7.不佳或不一致的命名规则
数据库设计人员和开发人员经常过于关注自己眼前的技术。而那些命名规则之类的非技术方面,往往会被他们置于优先级列表的最底层,或甚至完全被忽略掉。而这恰恰容易造成灾难性的恶果。
客观上说虽然命名规则可以由设计人员自行决定,但事实上,它对于数据库文档的重要程度还是不言而喻的(我们将在下面探讨不佳的文档)。由于数据库设在系统中相对持久和稳定,因此命名规则可以让那些没有参与过该构建项目的人员(如:后继的系统管理员、程序员、甚至是用户),不需要翻阅上千页的文档,就能够容易且快速地理解数据表与列的含义。当然,关于如何准确地命名各种数据表及其细节,目前业界尚无定论。
因此,最重要的就是要讲求“一贯性”。一旦您确定按照某个特定的方式来命名自己的对象,那么就请在整个数据库中贯彻该规则。对于数据表名称而言,我们应当尽可能让它能够完整或简约地描述所表示的对象,而每个列的名称则能够表示对象的属性。对于简单的数据库来说,这并不难以被实现;而对于需要构建相互引用关系的复杂数据表而言,严格遵循命名规则就是一件比较繁琐的事情了。
值得注意的是:此类规则不应该对列名或表名的字符长度有过分的限制,而且要避免使用那些不易理解、或记忆的首字母缩略词汇。例如:我们很难猜测出列名为CUST_DSCR的含义;而CUSTOMER_DESCRIPTION则会更好地表示出列名称的意义。
同时,我们也要避免重复。如果表的名称为“Students”,那么我们只需采用Name AddressGrade作为列名称便可,而不必重复地使用StudentNameStudentAddressStudentGrade。当然,我们也不应该擅自使用那些保留词。如果您将某个列命名为“Index”,那么可能会给系统造成混淆,并产生不必要的错误。因此,我们可以使用诸如StudentIndex之类的描述性前缀。
8. 不佳的文档
我们在上面提到过,数据库的命名规则往往会体现在相关的文档中。这些看似微不足道的文档准备工作,却时常让一些优秀的数据库设计“身败名裂”。在系统运营的过程中,不佳的文档会极大地阻碍运维团队进行各种故障排除、架构改进、升级和连续性保证等工作。
数据库设计者应当假想:如果自己某一天不再对自己的数据库提供支持,那么他所准备的相关文档应该能够让其他人轻松地接管后继的设计、开发或管理工作。因此,良好的文档必须包含对于各种列、表、关系和约束的定义,明示每一个元素的使用方式。如果您能适当地包含并说明某些预期值的范例,那就更具有参考价值了。
一些设计师可能会狭隘地将晦涩的文档,作为确保自己工作安全的一种手段,以体现除了自己之外,其他人无法理解目标数据库的稀缺性。这种短见的做法不但很容易被管理层所识破,而且还会给自己若干年后的系统改造、与代码改进工作挖下不少的“坑”。
9.不充分的测试
无论是软件研发也好,还是数据库设计也罢,都离不开严格的测试检验。可不幸的是,测试阶段往往会由于项目截至日期的邻近,而被无情地跳过。当然,这是一种玩火自焚的做法。一些本该在测试阶段被识别和解决的错误和不一致性,往往会给上线后的系统埋下各种隐患。
没有用户愿意使用、也没有管理员愿意维护一个填充bug的数据库。因此,在上线之前所进行的各种深入且广泛的数据库测试,会大大减少部署到生产环境中所可能出现的故障数量、和破坏程度。业界普遍认为:好的测试不是要去发现每一个bug,而是帮助您找到并修正大多数潜在的问题。
总结
众所周知,数据库的开发和设计是任何数据密集型项目的核心,它与各种业务应用都息息相关。因此,本文所列出的九种设计中的常见错误,都会在项目的推进和系统的运行中,对数据库的后续性能产生严重的影响,进而产生高昂的修复成本。因此,我们应当在设计的一开始就尽量避开这些坑点,以构建出真正适合项目预期的数据库。

【原标题】 9 of the Most Common Mistakes in Database Design (作者Mokhtar Ebrahim )
原文链接:https://dzone.com/articles/9-of-the-most-common-mistakes-in-database-design

  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-8-31 10:26:59 | 显示全部楼层
感谢版主大大的精彩分享!
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-8-31 20:21:12 | 显示全部楼层
我好像看错了
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-9-12 22:05:13 | 显示全部楼层
躲坑不再难。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 思科 CCO 登录 | 思科 CCO 注册   

本版积分规则

Archiver | 思科社区  

GMT+8, 2020-9-24 07:11 , Processed in 0.096474 second(s), 36 queries .

京ICP备11014401号-17

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

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