创建数据模型的最佳实践 [关闭]

Posted 2023-03-12

【中文标题】创建数据模型的最佳实践 [关闭]

【英文标题】：Best practices for creating a data model [closed]

【发布时间】：2011-10-29 00:57:11

【问题描述】：

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

【问题讨论】：

我强烈推荐的两本书：Information Modeling and Relational DatabasesPractical Issues in Database Management

【参考方案1】：

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

这些书是特定于数据库的，这里是针对 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 反模式书）。如果列将位于多个不同的表中，请使用相同的名称和数据类型。您要做的是不必因为数据类型不匹配而使用函数进行连接。

永远记住，数据库可以（并且将会）在应用程序之外进行更改。数据完整性所需的任何东西都必须在数据库中，而不是应用程序代码中。应用程序被替换后，数据将在那里很长时间。

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

彻底定义所需数据（包括正确的数据类型） 以及数据片段之间的关系（包括正确的标准化） 数据完整性 性能 安全 一致性（数据类型、命名标准等）

【讨论】：

非常感谢您提供这个完整而有趣的答案！

@HLGEM，我不同意您似乎给予“性能调整”的优先级。当然，性能优化是一个重要的话题，但它不一定是设计功能正确的数据模型的先决条件。数据库设计人员的首要职责是创建准确表示业务领域的数据模型。您可以使用与性能本身无关的数据库设计方法来做到这一点：识别事实类型、业务规则、依赖关系、规范化等。

无论如何，不​​能孤立地看待数据库的性能，因为数据库只是解决方案的一部分，所以性能调优往往是在不同的阶段，由不同的人来进行数据模型的创建。

@dportas，数据库设计中存在已知的性能痛点。如果您不知道它们是什么，那么您很可能会犯那些在拥有 10,000,000 条记录的生产系统中很难修复的错误。我并不是说这是唯一的考虑因素，但它是数据库成功的最关键因素之一。

【参考方案2】：

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

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

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

至于性能 - 我认为您应该首先设计可维护性，并且只有在您知道自己有问题时才能设计性能。有时，您提前知道性能将是一个主要问题 - 为 Facebook（或 Stack Exchange）设计数据库，设计包含大量数据（TB 及以上）或大量用户的数据库。大多数系统不属于那个阵营 - 所以我建议定期进行性能测试，使用代表性数据，以找出您是否有问题，并且仅在您可以证明必须这样做时进行调整。许多性能优化是以可维护性为代价的——例如，非规范化。

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

【参考方案3】：

虽然这不是一本书，但我还是推荐阅读Query evaluation techniques for large databases。它提供了查询处理的背景，这在很大程度上影响了您的架构设计，特别是对于数据密集型（例如分析）工作负载。它不那么动手，但我相信每个数据库设计人员都应该至少阅读一次:-)。

【讨论】：

论文也不错 :-) 我需要引用我的结果，所以书或论文 ;-)