有谁知道论文/书籍等。那个文件模式的数据库？例如，一个常见的经验法则是每个表都应该有一个主键，并且键应该是devoid of information content。所以我想知道是否有人写过关于设计关系数据库的设计模式的书或发表论文？
@Gaius，
这是数据库设计师需要权衡的问题 - 数据库结构的可能稳定性是什么？鉴于足够长的时间范围，没有什么是稳定的。或者说反过来，只要有足够长的视野，一切都会发生变化。代理键（理论上）永远不应该改变它的含义，因为它从来没有意义。
我想在那个特定的设计场景中要考虑的另一件事是谁会看到主键？如果主键是最终用户实际需要引用的东西，那么将它变成可以理解的东西是有意义的。但我想不出最终用户需要看到主键的许多情况;通常存在主键以允许DB引擎加速某些操作。
我最初想到的问题是找到数据库设计的设计模式，这些设计模式由比我更有经验的数据库设计者编写，以便希望避免一些容易避免的错误。如果有人编写过数据库设计反模式，那将会很有趣。
答案 0 :(得分：9)
具体来说，关于键：我强烈不同意键必须没有意义的奇怪想法。一般来说，我认为数据库是事实的集合;一旦你开始添加任意数字（如生成的密钥）和其他无关信息，它应该是一个警告标志。我建议this articly by Joe Celko了解有关密钥的更多信息。
更一般的说明：
针对不同业务的架构设计/数据模型的建议：
David C. Hay：数据模型模式：思想公约
相当古老，但有一个原因，它仍然在印刷
http://www.dorsethouse.com/books/dmp.html
也许不是很像模式，但仍然非常好： Stephane Faroult，Peter Robson：SQL的艺术 http://oreilly.com/catalog/9780596008949/
我可以推荐另一个： Vadim Tropashko：SQL设计模式 - SQL编程专家指南 http://www.rampant-books.com/book_2006_1_sql_coding_styles.htm
关于数据建模的系统教科书： Graeme Simsion＆amp; Graham Witt，“数据建模要点” http://www.elsevierdirect.com/product.jsp?isbn=9780126445510
也许你真的在寻找“风格指南”？我那样的话： Joe Celko：SQL编程风格 http://www.elsevierdirect.com/product.jsp?isbn=9780120887972
答案 1 :(得分：4)
E.F. Codd和C.J.Date的书籍是最明显的答案。我没有读过这本书，但我对作者很熟悉，可能还不错。
Lex de Haan和Toon Koppelaars的答案 2 :(得分：3)
实际上，我认为经验法则通常是尽可能使用自然键而不是代理...
因此，如果我有一个Invoice表和一个InvoiceDetail表，我们可以使用InvoiceNumber作为第一个的主键。它已存在于我们的数据中（我假设？）将是唯一的。对于第二个表格，我们可能会被困在需要代理键的情况下 - 无论它是否与发票编号一起作为复合编号加入。
无论如何，回到最初的问题...... hometoast的链接应该让你开始。
- Kevin Fairchild
答案 3 :(得分：2)
准确回答：yes。在'良好'的数据库设计上写了* *的信息。虽然你的经验法则肯定是有问题的。
答案 4 :(得分：2)
SQL Anti-Patterns非常容易阅读（不干）并且用相当清晰的术语解释了一些不同的潜在缺陷，你如何发现自己使用它们，以及如何/为什么要正确地做事。
答案 5 :(得分：1)
使用具有商业含义的主键（“自然键”）当然有其优点，但它可以使您的数据库非常难以重构。请谨慎使用，特别是如果有任何理由相信数据库结构会随着时间的推移而发生变化。