创建数据模型的最佳实践

时间:2011-08-17 15:14:32

标签: database database-design naming-conventions normalization

对于当前项目,我正在创建一个数据模型。有没有哪些资源可以找到一个好的数据模型的“最佳实践”?良好意味着灵活,高效,具有良好的性能,风格......一些示例问题是“列的命名”,“应该规范化的数据”,或“应该将哪些属性导出到自己的表中”。来源应该是一本书: - )

3 个答案:

答案 0 :(得分:8)

我个人认为你应该在开始建模数据库之前阅读一本关于性能调优的书。正确的设计可以创造一个与众不同的世界。如果您不是性能调优方面的专家,那么您就没有资格设计数据库。

这些书是特定于数据库的,这里是SQl Server的书。 http://www.amazon.com/Server-Performance-Tuning-Distilled-Experts/dp/1430219025/ref=sr_1_1?s=books&ie=UTF8&qid=1313603282&sr=1-1

在开始设计之前,您应该阅读的另一本书是关于反模式的。总是很高兴知道你应该避免做什么。 http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1313603622&sr=1-1

不要陷入设计灵活性的陷阱。人们使用它作为一种摆脱工作的方式来正确设计和灵活的数据库几乎总是表现不佳。如果超过5%的数据库设计依赖于灵活性,我认为您没有正确建模。我必须使用的所有最差的COTS产品都是为了灵活性而设计的。

任何体面的数据库书籍都将讨论规范化。您还可以在网上轻松找到这些信息。确保实际创建FK / PK关系。

就命名列而言,选择一个标准并坚持使用它。一致性比实际标准更重要。不要为列ID命名(请参阅SQL反模式书)。如果列将位于多个不同的表中,请使用相同的名称和数据类型。你要做的是因为数据类型不匹配而不必使用函数来进行连接。

永远记住数据库可以(并且将会)在应用程序之外进行更改。数据完整性所需的任何内容都必须在数据库中而不是应用程序代码中。在更换应用程序后很长时间内,数据就会存在。

数据库设计最重要的事情:

  • 彻底定义所需数据(包括正确的数据类型) 和数据之间的关系(包括正确的标准化)
  • 数据完整性
  • 性能
  • 安全
  • 一致性(数据类型,命名标准等)

答案 1 :(得分:2)

我读过的关于数据库系统设计的最好的书是“数据库系统简介”。 Joe Celko的SQL for Smarties书籍也值得一读。 假设您正在构建一个应用程序而不仅仅是一个数据库,并且假设您使用的是面向对象的语言,那么Craig Larman应用UML和模式就将数据库映射到对象进行了很好的讨论。

在定义“好”方面,根据我的经验,“可维护”可能是最重要的。数据库设计的可维护性意味着许多事情,例如坚持惯例 - 我经常推荐http://justinsomnia.org/2003/04/essential-database-naming-conventions-and-style/。规范化是另一种明显的可维护性策略。我经常建议对列类型慷慨 - 如果您发现不同国家/地区的邮政编码比美国更长,则很难更改应用程序。对于经验不足的开发人员,我经常建议使用视图来抽象复杂的数据关系。

可维护性的关键是测试和部署的能力。值得一读的是关于连续数据库集成(http://www.codeproject.com/KB/architecture/Database_CI.aspx) - 虽然与数据库模式的设计没有严格关联,但它是重要的上下文。

至于性能 - 我认为你应该首先设计可维护性,如果你知道有问题,只设计性能。有时,您事先知道性能将是一个主要问题 - 为Facebook(或Stack Exchange)设计数据库,设计具有大量数据(TB级或更高)或大量用户的数据库。大多数系统都不属于那个阵营 - 所以我建议定期进行性能测试,找到有代表性的数据,找出是否有问题,只有在你能证明必须时才进行调整。许多性能优化以可维护性为代价 - 例如,非规范化。

哦,一般来说,如果可以,请避免使用触发器和存储过程。这只是我的看法,但是......

答案 2 :(得分:1)

即使它不是一本书,我建议您阅读Query evaluation techniques for large databases。它提供了查询处理的背景,这在很大程度上影响了您的架构设计,尤其是对于数据密集型(例如,分析)工作负载。它不那么亲力亲为,但我相信每个数据库设计师都应该至少阅读一次: - )。