6. 所有域值的单一表
包罗万象的域表（domain table）并非是数据库设计的最佳方法。记住，关系型数据库的构建理念是：数据库中的每个对象都只代表一个事物，不可出现任何指代不清的数据集。通过导航主键、表名、列名、以及各种关系，应用能够快速地解读出数据集的含义。尽管如此，在进行数据库设计时，许多人总会情不自禁地滑向：数据表越来越多，数据库越来越复杂和混乱的深渊。
过去，业界的普遍做法是将多张表压缩到一张表之中，进而简化设计。但是这往往会带来效率低下、且难以操作等问题。而且SQL代码会随着变长，可读性也会有所下降。可见单一域表貌似一个抽象的文本容器，但它的确不是数据库设计的最佳方式。
那么，作为规范化的一部分，我们需要通过数据隔离和分解的方法，让每一行都只代表一个事物，同时让多个域表相互区别不同的事物。其好处在于：
u 让数据的查询更加容易。
u 使用外键约束来更自然地验证数据，而这正式单域表设计所无法实现的。因为在单域表中，每张表所需的各种键会变得难以维护。
u 每当您想为某个对象添加多种数据时，您只需简单地增加一到多列便可。
u 小型域表（small-domain tables）适合于存储在硬盘的单页上，而大型域表很可能会扩展到多个磁盘的多个扇区里。显然，将表存放在单页中就意味着我们可以通过对单个磁盘的读取，以快速提取数据。
u 因为这些域表很可能具有相同的底层用法与结构，因此拥有多个域表并不会妨碍您为所有的行启用同一编辑器。
7.不佳或不一致的命名规则
数据库设计人员和开发人员经常过于关注自己眼前的技术。而那些命名规则之类的非技术方面，往往会被他们置于优先级列表的最底层，或甚至完全被忽略掉。而这恰恰容易造成灾难性的恶果。
客观上说虽然命名规则可以由设计人员自行决定，但事实上，它对于数据库文档的重要程度还是不言而喻的（我们将在下面探讨不佳的文档）。由于数据库设在系统中相对持久和稳定，因此命名规则可以让那些没有参与过该构建项目的人员（如：后继的系统管理员、程序员、甚至是用户），不需要翻阅上千页的文档，就能够容易且快速地理解数据表与列的含义。当然，关于如何准确地命名各种数据表及其细节，目前业界尚无定论。
因此，最重要的就是要讲求“一贯性”。一旦您确定按照某个特定的方式来命名自己的对象，那么就请在整个数据库中贯彻该规则。对于数据表名称而言，我们应当尽可能让它能够完整或简约地描述所表示的对象，而每个列的名称则能够表示对象的属性。对于简单的数据库来说，这并不难以被实现；而对于需要构建相互引用关系的复杂数据表而言，严格遵循命名规则就是一件比较繁琐的事情了。
值得注意的是：此类规则不应该对列名或表名的字符长度有过分的限制，而且要避免使用那些不易理解、或记忆的首字母缩略词汇。例如：我们很难猜测出列名为CUST_DSCR的含义；而CUSTOMER_DESCRIPTION则会更好地表示出列名称的意义。
同时，我们也要避免重复。如果表的名称为“Students”，那么我们只需采用Name、 Address和Grade作为列名称便可，而不必重复地使用StudentName、StudentAddress或StudentGrade。当然，我们也不应该擅自使用那些保留词。如果您将某个列命名为“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
