数据库设计最佳实践

Question

我非常精通SQL Server,MySQL,Oracle等,但把这些数据库产品放在一边,是否有资源可以帮助我很好地设计关系数据库？是否有类似于数据库设计的模式或最佳实践？

我曾经多次看到数据库通常无法扩展; 人们有个人偏好,保留像isChecked列这样的列,它本质上是布尔值但存储为Char(1),其值为'Y'和'N'而不是0和1对我来说听起来更好.在进行数据库设计时不会犯常见错误的方法？

书籍或文章的链接将受到高度赞赏.

提前致谢.

Answer 1

几点:

• 尽可能多地了解问题领域.如果不知道自己要设计什么,就无法创建好的数据模型
• 熟悉 数据库提供程序提供的数据类型
• 如何正确使用规范化和设计表
• 性能:何时以及如何应用索引,如何编写有效的查询等.
• 何时以及如何使用不同的DB对象,如视图,过程,函数,触发器

Answer 2

有许多数据库设计模式.它们通常不是很好的形式化,因此您可能只需要查看大量的数据库设计.

例如,请参阅福勒关于设计模式的书籍.还有Nock的书.

有博客,比如数据库程序员.

有一本IEEE书籍,基于模式的数据库设计和实现.

谷歌搜索(链接)出现了24M的点击量.

Answer 3

我对此的看法有点逆势而上.我建议,不要过分强调数据库的设计.

有时这可能很难.对于内部LOB应用程序,业务的主流观点通常是DATA是主要资产,而软件在某种程度上是可消耗的.

我的建议是:不要买它.

实际上,资产是公司与数据交互的能力.查看它,操纵它,并根据它做出决定.

这意味着即使它们可能对数据赋予很高的价值,它们实际上重视的是您正在编写的软件.

这意味着我将把大部分精力集中在构建有效的用户体验上,而不是"设计完美的数据库".数据库实际上只是一种工具,可以让您提供用户体验.

关系数据模型的关键特性是数据和访问路径独立性.您可以添加列,更改密钥,引入或删除索引等,同时对使用它的应用程序的影响为零(或接近于零).

这使得数据库结构非常柔韧.

试图将数据库设计为"对未来具有灵活性"或"优化性能"主要是浪费精力.

更改数据库的结构对系统的影响相对较小.

此外,在您遇到需要扩展的场景之前,您实际上无法预测数据库的扩展方式.您最好的选择是等到遇到性能问题.然后专门解决它们.

但是,更改应用的用户体验通常会更加昂贵.UI工作非常耗时,通常需要一段时间才能正确完成.

所以,我建议你:

1. 只是制作一个糟糕的数据库设计
2. 对您遇到的实际性能方案做出反应
3. 将精力集中在用户体验上,而不是数据库上

Answer 4

对抗Dillie-O的建议.我建议您不要将所有查找放在一个表中.通常,这是试图强迫OO设计进入关系数据库.它可以完成,它符合OO开发人员的世界观,但它会导致严重的数据库设计.

跳转到Google并搜索"MUCK Tables",引导您讨论Massively Unified Code-Key Tables.或者,您可以查找"一个真正的查找表"进行讨论.或者甚至阅读Joe Celko的文章One True Lookup Table.

Answer 5

我没有在这个问题中找到我想要的东西,但是这个在DB设计中有一些设计模式的建议