我非常精通 SQL Server、MySQL、Oracle 等，但抛开这些数据库产品不谈，是否有资源可以帮助我很好地设计关系数据库？是否有类似数据库设计的模式或最佳实践之类的东西？
我曾多次看到数据库通常不可扩展；人们有个人偏好，喜欢保留像 isChecked 列这样的列，它本质上是布尔值，但存储为 Char(1)，其值像 'Y' 和 'N' 而不是 0 和 1，这对我来说听起来更好。做数据库设计时不犯常见错误的方法？
我们非常感谢您提供书籍或文章的链接。
提前致谢。
【问题讨论】：
标签： database-design
几点：
【讨论】：
有许多数据库设计模式。它们通常没有很好的形式化，因此您可能需要简单地查看大量数据库设计。
例如，请参阅Fowler's books 了解设计模式。还有Nock's Book。
有博客，比如database programmer。
有一本 IEEE 书，On Pattern-Based Database Design and Implementation。
Google 搜索 (link) 获得了 2400 万次点击。
【讨论】：
我对此的看法有些相反。 我建议，不要过分强调数据库的设计。
有时这可能很难。对于内部 LOB 应用程序，企业的主流观点通常是数据是主要资产，而软件在某种程度上是可消耗的。
我的建议是：不要买。
实际上，资产是公司与数据交互的能力。查看它，操纵它，并根据它做出决定。
这意味着，即使他们可能高度重视数据，但他们实际重视的是您正在编写的软件。
这意味着我会将您的大部分精力集中在构建有效的用户体验上，而不是“设计完美的数据库”上。数据库实际上只是一种工具，可让您提供用户体验。
关系数据模型的关键特性是数据和访问路径的独立性。您可以添加列、更改键、引入或删除索引等，同时对使用它的应用程序产生零影响（或接近于零）。
这使得数据库结构非常柔韧。
试图将数据库设计为“面向未来”或“优化性能”大多是徒劳的。
更改数据库的结构对您的系统的影响相对较小。
此外，在遇到需要扩展的场景之前，您真的无法预测数据库将如何扩展。最好的选择是等到遇到性能问题。然后具体解决它们。
但是，更改应用的用户体验通常会更昂贵。 UI 工作很耗时，而且通常需要一段时间才能做好。
所以，我建议你：
【讨论】：
反驳 Dillie-O 的建议。我建议您不要将所有查找放在一张表中。通常，这是将 OO 设计强制到关系数据库中的一种尝试。可以做到，并且符合 OO 开发人员的世界观，但会导致数据库设计瘫痪。
跳转到 Google 并搜索“MUCK Tables”，这将引导您讨论大规模统一代码键表。或者，您可以寻找“一个真正的查找表”进行讨论。甚至可以阅读 Joe Celko 的文章 One True Lookup Table 。
【讨论】：
我没有在这个问题中找到我要找的东西，但是this one 有很多关于 DB 设计中的设计模式的建议
【讨论】：
不存储计算值
例如，您有表格“正方形”，列“宽度”。不需要列“面积”，因为可以通过 width ^ 2
计算【讨论】：
与任何事情一样，这里的答案是“视情况而定”。
数据库可以用来做不同的事情，其中一些事情在设计和开发中需要相反的方向。
OLTP 数据库系统的设计与用作报告或仓储解决方案的系统完全不同。第一个通常是规范化的，而仓库通常是非规范化的。这有助于系统获得预期行为所需的性能。
即使在其中的一部分内，根据使用情况是读重还是写重，不同的设计决策也可能是合适的。
最好的办法是针对与您尝试构建的应用程序类型相对应的较小的数据库开发部分研究最佳实践。
【讨论】：
我读过的关于数据库设计的最好的书是 Michael J Hernandez 的“Database Design for Mere Mortals”。这个名字听起来像是一本初学者的书，但任何级别的人都可以从中获得知识。它也是独立于平台的，因为它处理的是查看数据本身以及如何正确组织它 - 而不是所使用的技术。
他还写了一本关于编写查询的书，名为《SQL Queries for Mere Mortals》，我听说（我自己还没有读过这本书）相当不错。
【讨论】：
关系数据库是一个非常强大的抽象；它是事实和谓词演算的集合。不仅如此，SQL 通过一个用于检查行和另一个用于更改行的子句来强制执行命令查询分离。
当您将数据库视为真值推理引擎时，设置一个不允许矛盾从您正在建模的数据中流出的设置是有意义的。因此，要有效地使用关系数据库，您需要正确设计数据库。与面向对象程序的设计不同，对于应该如何设计关系数据库存在共识。合理的数据库设计方法是normalise。大多数人标准化到第三范式，但实际上你可以升到第五范式。
如果可能，您希望从数据库中删除空列值。如果您同意我将数据库视为真理推理引擎的观点，那么空值就是一个真正的问题。当您在数据库中有空值时，排中定律不 成立。这使得数据库的任何给定属性的“矛盾证明”比没有空值的情况更加困难。空值不必要地使数据库的语义复杂化。
有时出于性能原因需要打破规范化规则。但是，在您获得数据关于什么是特别慢的查询之前，不要这样做。通常，您可以通过仔细更改索引而不是反规范化来简单地加快查询速度。
最后，关于存储过程而不是直接查询。在一个体面的数据库上，您可以独立于基础表对存储过程设置安全权限。这本身就足以考虑广泛使用存储过程。使用存储过程，您可以构建比直接 SQL 访问更严格的安全模型。
【讨论】：
最著名的最佳实践可能是数据库规范化。这组技术允许您设计数据库，以便删除多余的项目，并对字段进行逻辑分组。
【讨论】：
如果您没有在架构的描述列中记录枚举，以便我可以弄清楚其中的“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'
【讨论】：
Michael J. Hernandez 的书为凡人设计的数据库写得很好，而且很容易阅读。它应该回答你所有的问题。
Hernandez 还与 John L. Viescas 合着了 SQL Queries for Mere Mortals。
这些书每本大约 60 美元。我正在努力寻找《凡人之问》的 CD，因为我弄丢了我的。如果有人有副本，请告诉我。
【讨论】：
我会说，只要数据库是规范化的，并且如果您正在制作一个 VLDB，然后正确地对其进行分区，那么您应该没问题。其他最佳实践包括对存储过程使用 CRUD 并确保所有表正确级联。大多数其他一切都是主观的。使用“Y/N”是尚未引入比特时的老式数据库编程。它也可以用于可扩展性目的，例如“Y/N/Maybe”，但如果是这种情况，basast 实践会说要对其进行规范化并制作一个查找表。
【讨论】：
我们在这里使用的一个非常好的概念是“查找代码”表。如果您有一个数据库，其中包含对有效编码或类型等项目的大量引用，请将所有这些引用保存在单个 LookupCode 表中，该表基于 CodeGroup 和代码本身。
我们为代码的活动状态保留了一个附加标志，以及一些可选的数字列，如果需要以任何方式对给定的查找代码进行排序或计算，可以使用这些列。
通过这样做，您可以消除大量分散在架构周围的小表格。现在这样做的一个缺点是表的主键是代码组和代码本身，所以没有附加到引用给定代码的“主”表的外键，但是一点点应用程序中的强制执行很容易适应这一点。
【讨论】：