等考三级数据库设计经验谈1:设计数据库之前

一个成功的管理系统是由【50%业务+50%软件】组成的，50%成功的软件是由【25%数据库+25%程序】组成的。数据库的设计是一个关键因素。如果把企业的数据比作生命所必需的血液，那么数据库的设计就是应用程序中最重要的部分。关于数据库设计的资料很多，大学学位课程也有专门的讲座。但是，正如我们一再强调的，再好的老师也比不上经验的传授。于是我总结了自己这些年走的弯路和经验，在网上找了一些在数据库设计方面颇有造诣的专业人士，教你一些数据库设计的技巧和经验。从这些技巧中挑选了60个，汇编成这篇文章。为了方便索引，内容分为五个部分:
第一部分——设计数据库之前
这一部分列出了12项基本技能，包括命名规范和定义业务需求。
第2部分-设计数据库表
共24个指导性提示，涵盖了表中字段的设计以及应该避免的常见问题。
第三部分——选键
如何选键？这里有10个技巧，具体涉及正确使用系统生成的主键，以及何时以及如何索引字段以提高性能等。
第4部分-确保数据完整性
讨论了如何保持数据库的清晰和健壮，以及如何最大限度地减少有害数据。
第五部分——各种小技巧
以上四部分没有包括的其他技能多种多样。有了它们，我希望你的数据库开发会更容易。
第1部分-在设计数据库之前
检查现有环境
在设计新的数据库时，您不仅应该仔细研究业务需求，还应该仔细研究现有系统。大多数数据库项目不是从零开始构建的；通常，组织中总会有一个现有的系统(可能无法实现自动计算)来满足特定的需求。很明显，现有的系统并不完善，否则你就不用建立新的系统了。但是对旧制度的研究可以帮助你发现一些你可能忽略的微妙问题。总的来说，对你来说，审视现有的制度是绝对有益的。
定义标准对象命名约定
您必须定义数据库对象的命名约定。对于数据库表，从项目开始就需要确定表名是复数还是单数。此外，应该为表别名定义简单的规则(例如，如果表名是一个单词，别名取单词的前四个字母；如果表名是两个单词，取每个单词的前两个字母组成别名，长度为4个字母；如果表名由三个单词组成，不妨取前两个单词中的一个，然后从最后一个单词中取出两个字母，结果仍然是4个字母的别名，以此类推。)对于工作表，表名可以以work_为前缀，后跟使用该表的应用程序的名称。表中的列[字段]应该采用一整套键的设计规则。例如，如果键是数值类型，可以使用_n作为后缀；如果是字符类型，可以使用后缀_c。列[字段]名称应该使用标准的前缀和后缀。再比如，如果你的表中有很多“money”字段，不妨给每一列[字段]加一个_m后缀。此外，日期列[字段]以d_开头。

检查表名、报表名和查询名之间的命名约定。您可能很快会被这些不同的数据库元素的名称弄糊涂。如果您坚持统一命名这些数据库的不同部分，至少您应该在这些对象名称的开头使用前缀，如table、query或report。
如果采用microsoft access，可以使用qry、rpt、tbl、mod等符号来标识对象(如tbl_employees)。我在处理sql server的时候用tbl来索引表，但是我用sp_company(现在的sp_feft_)来标识存储过程，因为有时候如果找到更好的解决方案我会保存好几个副本。当我实现sql server 2000时，我使用udf_(或类似的标记)来标识我编写的函数。
工欲善其事，必先利其器
使用理想的数据库设计工具，如sybase公司的powerdesign。她支持pb、vb、delphe等语言，可以通过odbc连接市面上30多种流行的数据库，包括dbase、foxpro、vfp、sql server等。以后有机会我会重点关注powerdesign的使用。
获取数据模式资源手册
正在寻找示例模式的人可以阅读《数据模式资源手册》这本书，作者是len silverston、w. h. inmon和kent graziano，这是一本值得拥有的数据建模书籍。这本书包括涵盖各种数据领域的章节，如人员、机构和工作效率。其他的，也可以参考相关书籍。
考虑未来，但不要忘记过去的教训。
我发现问用户对未来需求变化的看法非常有用。这样可以达到两个目的:第一，你可以清楚地了解应用程序设计应该在哪些地方更加灵活，如何避免性能瓶颈；其次，你知道当有一个未确定的需求变化时，用户会和你一样惊讶。
一定要记住过去的经验教训！我们开发者也应该通过分享自己的经历和经验来互相帮助。即使用户认为他们不再需要任何支持，我们也应该对他们进行这方面的教育。我们都面临过这样的时刻，“我希望我做到了这一点……”。
设计逻辑先于物理实践。深入物理设计之前的设计逻辑。随着大量case工具的出现，你的设计可以达到相当高的逻辑水平，你通常可以更好地从整体上理解数据库设计的各个方面。
了解您的业务
在您100%确定系统满足客户需求之前，不要在您的er(实体关系)模式中添加任何数据表(为什么，您还没有模式吗？请参考技巧9)。了解你的业务可以在后期发展阶段节省很多时间。一旦你明确了你的业务需求，你就可以自己做很多决定。
一旦你认为你已经定义了业务内容，你就与客户进行了系统的沟通。使用客户的术语，并向他们解释您的想法和听到的内容。同时也要用可能、意志、必须等词语来表达系统的关系基础。这样你就可以让你的客户纠正你自己的理解，然后做下一步的er设计。
创建数据字典和er图表
一定要花一些时间来创建er图表和数据字典。它至少应该包含每个字段的数据类型以及每个表中的主键和外键。创建er图表和数据字典有点费时，但对于其他开发人员来说，理解整个设计是绝对必要的。越早创建越好，以避免将来可能出现的混乱，这样任何了解数据库的人都可以知道如何从数据库中获取数据。
er chart等最新文档的重要性怎么强调都不为过，它对于显示表之间的关系非常有用，而数据字典解释了每个字段的用途以及任何可能的别名。这对于sql表达式的文档来说是绝对必要的。
创建模式
一张图胜过千言万语:开发人员不仅要阅读和实现它，还要用它来帮助自己与用户对话。该模式有助于提高协作效率，因此在早期数据库设计中几乎不可能出现大问题。图案不一定要复杂；它甚至可以像在一张纸上手写一样简单。只需要保证它上面的逻辑关系以后能产生效益就可以了。
从输入和输出开始
在定义数据库表和字段要求(输入)时，您应该首先检查现有的或设计的报表、查询和视图(输出)，以决定哪些表和字段是支持这些输出所必需的。举个简单的例子:如果一个客户需要一个按邮政编码进行排序、细分和汇总的报表，你应该确保它包含一个单独的邮政编码字段，而不是将邮政编码添加到地址字段中。
报表技巧
了解用户通常如何报表数据:批处理还是在线报表提交？时间间隔是每天、每周、每月、每季度还是每年？如有必要，您还可以考虑创建一个汇总表。系统生成的主键很难在报表中管理。当在具有系统生成的主键的表中使用辅键进行搜索时，用户经常会返回大量重复数据。这种检索性能低，容易造成混乱。
了解客户需求
看起来这应该是显而易见的，但需求恰恰来自于客户(这里要从内部和外部客户的角度来考虑)。不要依赖用户写下来的需求。真正的需求在客户的脑子里。你应该要求客户解释他们的需求，随着开发的继续，你应该始终要求客户确保他们的需求仍然在开发的目的中。一个不变的真理是:“看到才知道自己想要什么”必然会导致大量的返工，因为数据库不符合客户从来没有写下来的需求。更糟糕的是，你对他们需求的解释只属于你，而且可能是完全错误的。