Question

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

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

高度赞赏书籍或文章的链接。

提前致谢。

Answer 1

几点：

尽可能多地了解问题域。如果不知道你为
熟悉数据库提供商提供的数据类型
如何正确使用规范化和设计表格
效果：何时以及如何应用索引，如何编写有效的查询等。
何时以及如何使用不同的数据库对象，如视图，过程，函数，触发器

Answer 2

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

例如，请参阅Fowler's books有关设计模式的信息。还Nock's Book。

有博客，例如database programmer。

有一本IEEE书，On Pattern-Based Database Design and Implementation。

Google搜索（link）点击率达到24M。

Answer 3

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

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

我的建议是：不要买它。

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

这意味着即使他们可能对数据有很高的价值，他们实际看重的是您正在编写的软件。

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

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

这使数据库结构非常柔韧。

尝试将数据库设计为“对未来具有灵活性”或“优化性能”主要是浪费精力。

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

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

但是，更改应用的用户体验通常会更加昂贵。 UI工作非常耗时，通常需要一段时间才能做好。

所以，我建议你：

只是制作糟糕的数据库设计
对您遇到的实际性能方案做出反应
专注于用户体验，而不是数据库

Answer 4

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

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

Answer 5

我没有在这个问题中找到我想要的内容，但是this one对数据库设计中的设计模式提出了一系列建议

Answer 6

不存储计算值

示例，您有“Squares”表，其中“width”列。无需创建列“区域”，因为可以通过宽度^ 2

计算

Answer 7

与任何事情一样，这里的答案是“它取决于。”

数据库可以用来做不同的事情，其中一些事情需要在设计和开发方面有相反的方向。

OLTP数据库系统的设计与用作报告或仓储解决方案的系统完全不同。第一种通常是标准化的，仓库通常是非标准化的。这有助于系统获得预期的性能。

即使在一部分内容中，根据使用量是重读还是重读，不同的设计决策可能是合适的。

最好的办法是研究与您尝试构建的应用程序类型相对应的更小的数据库开发部分的最佳实践。

Answer 8

我读过的关于数据库设计的最好的书是Michael J Hernandez撰写的“数据库设计”。这个名字听起来像是一本初学者的书，但任何级别的人都可以从中获取知识。它也是独立于平台的，因为它涉及查看数据本身以及如何正确组织它 - 而不是正在使用的技术。

他还写了一本关于编写名为“SQL Queries for Mere Mortals”的书，我听说过（我自己还没有读过这篇文章）是非常好的。

Database Design for Mere Mortals

Answer 9

关系数据库是一个非常强大的抽象;它是事实和谓词演算的集合。不仅如此，SQL通过一个用于检查行的子句和另一个用于更改行的子句来强制执行命令查询分离。

当您将数据库视为真值推理引擎时，有一个设置不允许从您正在建模的数据中产生矛盾。因此，要有效地使用关系数据库，您需要正确地进行数据库设计。与面向对象程序的设计不同，关于如何设计关系数据库存在共识。数据库设计的正确方法是normalise，只要它是明智的。大多数人正常化到第三范式，但事实上你可以达到第五范式。

如果可能，您希望从数据库中删除空列值。如果您同意我将数据库视为真值推理引擎，那么空值就是一个真正的问题。当数据库中有空值时，排除中间的定律不成立。这使得数据库的任何给定属性的“通过矛盾证明”比没有空值更难。 Null会不必要地使数据库的语义复杂化。

出于性能原因，有时需要打破规范化规则。但是，在具有数据之前，请不要执行此操作，特别是查询的速度很慢。通常，您可以通过仔细更改索引而不是非规范化来简化查询。

最后，关于存储过程的一个词而不是直接查询。在一个不错的数据库上，您可以独立于基础表设置存储过程的安全权限。这本身就足以考虑广泛使用存储过程。使用存储过程，您可以构建比直接SQL访问更严格的安全模型。

Answer 10

最着名的最佳实践可能是数据库规范化。这组技术允许您设计数据库，以便删除冗余项目，并按字节顺序对字段进行分组。

Answer 11

如果你没有在架构的描述栏中记录枚举，那么我可以弄清楚'5'在这里的含义：

Select name from peeps where accountStatusId = 5

然后执行此操作

使用表来枚举字段。例如：

Select name 
from peeps p 
join accountStatus s 
on p.accountStatusID = s.asid 
where s.accountStatus = 'ActiveDude'

Answer 12

迈克尔·埃尔南德斯的书数据库设计的美妙人物写得很好，而且很容易阅读。它应该回答你所有的问题。

Hernandez还与John L. Viescas共同撰写了 SQL Queries for Mere Mortals 。

每本书约60美元。我正试图找到CD for Quare for Mere Mortals，因为我失去了我的。如果有人有副本，请告诉我。

Answer 13

我会说，只要数据库是规范化的，如果你正在制作VLDB然后正确分区，那么你应该没问题。其他最佳实践包括对存储过程使用CRUD并确保所有表都正确级联。其他一切都是主观的。使用“Y / N”是从尚未引入位的旧学校数据库编程。它也可以用于“Y / N / Maybe”之类的可扩展性目的，但如果是这样的话，那么bast实践就会说它可以规范化并创建一个查找表。

Answer 14

我们在这里使用的一个已被证明相当不错的概念是“查找代码”表。如果您的数据库有很多对有效编码或类型等项的引用，请将它们全部保存在一个LookupCode表中，该表基于CodeGroup和Code本身。

我们为代码的活动状态保留了一个额外的标志，以及一些可选的数字列，如果给定的查找代码需要以任何方式进行排序或计算，则可以使用这些列。

通过这样做，您可以消除在您的架构周围散布的大量小小桌子。现在其中一个缺点是表的主键是代码组和代码本身，因此没有外键附加到引用给定代码的“主”表，但是一点点应用程序中的强制执行很容易适应这种情况。

数据库设计最佳实践

14 个答案: