有谁知道文件/书籍等。数据库的文档模式？例如，一个常见的经验法则是每个表都应该有一个主键，并且该键应该是devoid of information content。所以我想知道是否有人写过一本关于设计关系数据库设计模式的书或发表过论文？数据库模式
@Gaius，
这是数据库设计人员需要权衡的问题 - 什么是数据库结构的可能稳定？鉴于足够长的视野，没有什么是稳定的。或者说相反的话，考虑到足够长的视野，所有事情都会发生变化。代理关键词（理论上）不应该改变其含义，因为它从来没有意义开始。
我想在特定的设计场景中考虑的另一件事是谁会看到主键？如果主键是最终用户实际需要参考的东西，那么将其作为他们可以理解的东西是有意义的。但我想不到最终用户需要查看主键的许多情况;通常会出现主键以允许数据库引擎加速某些操作。
我在问这个问题最初的想法是找到那个被更有经验的数据库设计比自己编纂以，希望避免一些容易避免错误的数据库设计的设计模式。如果有人曾经编写过数据库设计的反模式，那么阅读会很有趣。
具体而言，关于键：我强烈反对奇怪的想法，即键必须没有意义。总的来说，我认为数据库是一系列事实;只要你开始向其中添加任意数字（如生成的密钥）和其他不相关的信息，它应该是一个警告标志。我建议this articly by Joe Celko更多关键。
更一般注意事项：
建议架构设计/针对不同的业务数据模型： 大卫C.干草：数据模型模式：思想 比较旧的约定，但有一个原因，它仍然在打印
http://www.dorsethouse.com/books/dmp.html
也许不是非常图案状的，但还是很不错的： 斯特凡Faroult，彼得·罗布森：SQL http://oreilly.com/catalog/9780596008949/
的艺术另外一个，我可以建议： 瓦迪姆Tropashko：SQL设计模式 - 专家指南SQL编程 http://www.rampant-books.com/book_2006_1_sql_coding_styles.htm
系统化教科书有关数据建模： 格雷姆Simsion &格雷厄姆威特，“数据建模要点” http://www.elsevierdirect.com/product.jsp?isbn=9780126445510
也许你实际上是在寻找一个“风格指南”？我的话： 乔·塞科：SQL编程风格 http://www.elsevierdirect.com/product.jsp?isbn=9780120887972
准确回答：yes。在'良好'的数据库设计上写有信息。虽然你的示例经验法则当然是可疑的。
E.F. Codd和C.J. Date的书是最明显的答案。我没有读过这本书，但我对作者很熟悉，可能相当不错。
Applied Mathmatics for Database Professionals Lexx de Haan和Toon Koppelaars。
很明显，你没有发现有必要命名它们吗？ – brian 2009-03-02 20:43:02
其实我觉得经验法则通常是使用自然键而不是替代尽可能...
所以，如果我有，例如，发票表和InvoiceDetail表，我们可以可能使用InvoiceNumber作为我们的第一个主键。它已经存在于我们的数据中（我假设？）将是唯一的。对于第二张表，我们可能会被卡住，需要一个代理键，但是 - 无论它是否加入发票号码为复合或不合并。
无论如何，回到原来的问题... hometoast的链接应该让你开始。
- 凯文飞兆半导体
使用自然键与替代键的想法是一个主要争论。许多人会争论你应该总是使用代理键。 – 2010-10-12 19:46:20
使用具有商业含义（“自然键”），固然有其优点，但它可以使重构你的数据库非常困难的主键。谨慎使用，特别是如果有任何理由相信数据库结构会随着时间而改变。
SQL Anti-Patterns由Bill Karwin非常容易阅读（未干）和相当明确的语言介绍了许多不同的潜在的陷阱，你怎么可能发现自己使用它们，以及如何/为什么要做正确的事情。
感谢您的指针。 – 2012-10-30 14:08:17
使用'自然'键的风险是它们可以改变;代理键不能改变。 Celko的文章没有对价值做出更好的判断。另请参阅http://stackoverflow.com/questions/159087/composite-primary-keys-versus-unique-object-id-field#159247 – 2008-10-17 03:43:37