有誰知道文件/書籍等。數據庫的文檔模式？例如，一個常見的經驗法則是每個表都應該有一個主鍵，並且該鍵應該是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