Database Patterns本问题已经有最佳答案，请猛点这里访问。
有谁知道论文/书籍/等。数据库的那个文档模式？例如，一个普遍的经验法则是，每个表都应有一个主键，并且该键应没有信息内容。所以我想知道是否有人写过一本书或发表过有关设计关系数据库的设计模式的论文？ @Gaius， 这是数据库设计人员需要权衡的问题-数据库结构的可能稳定性是什么？在很长一段时间内，没有什么是稳定的。换句话来说，在很长一段时间内，一切都会发生变化。代理键(理论上)永远不要更改其含义，因为它永远都没有意义。 我猜在该特定设计方案中要考虑的另一件事是谁将看到主键？如果主键是最终用户实际需要参考的东西，那么使其成为他们可以理解的东西是有意义的。但是我无法想到最终用户需要看到主键的许多情况。通常，存在主键是为了允许数据库引擎加快某些操作的速度。 我提出这个问题的最初想法是找到数据库设计模式，这些模式是由比我本人更有经验的数据库设计人员编写的，从而希望避免一些容易避免的错误。如果有人曾经编纂数据库设计反模式，那将是很有趣的阅读。 具体来说，关于键：我强烈不同意这个奇怪的想法，即键必须没有意义。总的来说，我认为数据库是事实的集合。一旦开始向其中添加任意数字(如生成的键)和其他不相关的信息，它应该是一个警告信号。我建议乔·塞尔科(Joe Celko)巧妙地提出有关密钥的更多信息。 更一般的注意事项：
针对不同业务的架构设计/数据模型的建议：
也许不是很像模式，但是仍然非常好：
我可以推荐的另一个：
有关数据建模的系统教科书：
也许您实际上正在寻找"样式指南"？在这种情况下： 最明显的答案是E.F. Codd和C.J. Date的书。我没有读过这本书，但我对作者很熟悉，它可能相当不错。 Lexx de Haan和Toon Koppelaars为数据库专业人员提供的应用数学。 实际上，我认为经验法则通常是尽可能使用自然键而不是替代键... 因此，例如，如果我有一个Invoice表和一个InvoiceDetail表，则可以在第一个表上使用InvoiceNumber作为主键。它已经存在于我们的数据中，并且(我认为？)将是唯一的。对于第二张表，我们可能会需要使用代理键，但是，无论它是否以复合形式连接到发票号。 无论如何，回到最初的问题... hometoast的链接应该可以帮助您入门。 -凯文·费尔柴尔德(Kevin Fairchild) Bill Karwin撰写的SQL Anti-Patterns非常易于阅读(不干涩)，并且以相当清晰的术语解释了许多不同的潜在陷阱，如何使用它们以及如何/为什么做正确的事情。 要确切回答：是的。在"好的"数据库设计上有成千上万的信息。尽管您的经验法则当然值得怀疑。 使用具有业务含义的主键("自然键")当然有其优点，但是它会使重构数据库变得非常困难。请谨慎使用，尤其是在有任何理由相信数据库结构会随着时间而改变的情况下。 |
