我很熟悉SQL Server，MySQL，Oracle等，但將這些數據庫產品放在一邊，有沒有一種資源可以幫助我設計好關係數據庫？有沒有像數據庫設計的模式或最佳實踐？數據庫設計最佳實踐
我曾經看過幾次數據庫往往不可擴展;人們有個人喜好保持像isChecked列這是布爾本質上的列，但存儲爲Char（1）與值'Y'和'N'而不是0和1，這對我來說聽起來更好。在數據庫設計時不要犯下常見錯誤的方法？
鏈接到書籍或文章將不勝感激。
在此先感謝。
的幾點：
可能最着名的最佳實踐是數據庫規範化。這套技術使您可以設計數據庫，以便刪除冗餘項目，並且邏輯上將字段分組。
他們在學校宣講這一點..進入現實世界，我來發現這並不總是一件好事！ – 2008-12-22 21:50:18
和其他東西一樣，這裏的答案是「它取決於」。
數據庫可以用來做不同的事情，其中一些事情將需要在設計和開發中的相反方向。
OLTP數據庫系統的設計完全不同於用作報告或倉儲解決方案的OLTP數據庫系統。第一個常常是正常化的，而且倉庫通常是非標準化的。這有助於系統獲得預期行爲所需的性能。
即使在其中的一部分內容中，取決於使用情況是重讀還是重寫，不同的設計決策可能是合適的。
最好的選擇是查看與您正在嘗試構建的應用程序類型相對應的小部分數據庫開發的最佳實踐。
我們在這裏使用的一個很好的概念是「查找代碼」表。如果您的數據庫中包含大量對有效代碼或類型等項目的引用，請將它們全部保存在基於CodeGroup和代碼本身的單個LookupCode表中。
我們爲代碼的活動狀態保留一個額外的標誌，以及一些可選的數字列，如果給定的查找代碼需要按任何方式排序或計算，可以使用這些數字列。
通過這樣做，可以避免在模式中散佈大量小小的表格。現在的一個缺點是表的主鍵是代碼組和代碼本身，所以沒有外鍵附加到引用給定代碼的「主」表，但有一點應用程序中的執行很容易適應這一點。
-1：這也掩蓋了連接到表的基數，使得數據完整性更難執行，並且被廣泛認爲是不好的做法。 – 2008-12-22 21:56:59
我會說，只要數據庫是正常化的，如果你正在做一個VLDB然後正確的分區，那麼你應該沒問題。其他最佳實踐包括使用CRUD存儲過程並確保所有表正確級聯。其他的一切都是主觀的。使用「是/否」是從尚未引入位的舊學校數據庫編程。它也可以用於可伸縮性的目的，比如「Y/N/Maybe」，但是如果這樣的話，bast的實踐會說要規範化並製作查找表。
我曾經閱讀過的有關數據庫設計的最好的書是Michael J Hernandez的「單純的凡人的數據庫設計」。這個名字聽起來像是一本初學者書，但任何級別的人都可以從中獲得知識。它還與平臺無關，因爲它涉及查看數據本身以及如何正確組織數據 - 而不是使用的技術。
他還寫了一本關於編寫查詢的書，名叫「SQL查詢僅僅是凡人」，我聽說過（還沒有自己讀過這篇文章）非常好。
有衆多的數據庫設計模式。它們通常不會很好地形式化，因此您可能只需要查看大量的數據庫設計。
關於設計模式，請參閱Fowler's books。另外Nock's Book。
有博客，如database programmer。
有一本IEEE書，On Pattern-Based Database Design and Implementation。
谷歌搜索（link）出現24M點擊。
+1對於Marting Fowler – abatishchev 2010-04-15 09:59:56
+1對於Nock先生...這本書是創業板！ – Perpetualcoder 2010-12-22 17:29:52
不存儲計算值
例如，表格「寬度」爲「Squares」。無需製作「區域」列，因爲這可以通過寬度來計算^ 2
我對此的看法有點逆轉。 我會建議，不要過分強調數據庫的設計。
有時候這可能很難。對於內部LOB應用程序，業務流行的觀點往往是DATA是主要資產，因爲軟件有點消耗。
我的建議是：不要買它。
實際上，資產是公司與數據交互的能力。查看它，操縱它，並根據它做出決定。
這意味着即使它們可能會對數據賦予較高的價值，但它們實際評估的是您正在編寫的軟件。
這意味着我將把大部分精力集中在構建有效的用戶體驗上，而不是「設計完美的數據庫」上。數據庫實際上只是一個工具，可讓您提供用戶體驗。
關係數據模型的關鍵特徵是數據和訪問路徑的獨立性。您可以添加列，更改鍵，引入或刪除索引等，同時對使用它的應用程序產生零影響（或接近於零）。
這使得數據庫結構非常靈活。
試圖設計數據庫以「對未來靈活」或「優化性能」主要是浪費精力。
更改數據庫的結構對系統的影響相對較小。
此外，您真的無法預測數據庫如何進行擴展，直到遇到您需要擴展的場景。你最好的選擇是等到你遇到性能問題。然後專門解決它們。
但是，更改應用程序的用戶體驗通常更昂貴。 用戶界面工作非常耗時，通常需要一段時間才能正確使用。
所以，我建議你：
，如果你不記錄在架構中的描述列枚舉，這樣我可以找出「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'
爲了對抗Dillie-O的建議。我建議你不要把你所有的查找到一個表。一般來說，這是將OO設計強制爲關係數據庫的嘗試。它可以完成，它符合面向對象開發人員的世界觀，但會導致數據庫設計的癱瘓。
跳到Google並搜索「MUCK表」，這會引導您討論大規模統一代碼鍵表。或者，您可以查找「一個真正的查找表」進行討論。甚至可以閱讀Joe Celko的文章One True Lookup Table。
關係數據庫是一個非常強大的抽象;它是事實和謂詞演算的集合。不僅如此，SQL通過一個子句檢查行而另一個子句更改行來強制執行命令查詢分離。
當您將數據庫視爲真實推理引擎時，建立一個不允許矛盾從您正在建模的數據中流出的設置是有意義的。因此，要有效使用關係數據庫，您需要正確地設計數據庫設計。與面向對象程序的設計不同，關於如何設計關係數據庫存在共識。只要合理，數據庫設計的正確方法是normalise。大多數人正常化到第三範式，但實際上你可以達到第五範式。
如果可能，您希望從數據庫中清空空列值。如果你同意我對數據庫的看法是一個真理推理引擎，那麼空值是一個真正的問題。當你在數據庫中有空位時，排除中間的規律確實是而不是。這使得數據庫的任何特定屬性的「矛盾證明」變得更加困難，因爲它沒有空值。空值不必要地使數據庫的語義複雜化。
由於性能原因，有時需要打破規範化規則。但是，在你有數據之前不要這樣做，特別是查詢特別慢。通常你可以通過仔細改變索引來加速查詢，而不是非規範化。
最後，關於存儲過程而不是直接查詢。在體面的數據庫上，您可以獨立於基礎表設置存儲過程的安全權限。這本身就足以充分考慮廣泛使用存儲過程。使用存儲過程，您可以構建比直接SQL訪問所能實現的更嚴格的安全模型。
我沒有找到我在這個問題尋找，但this one在DB設計
這是荒謬的，這是封閉，沒有建設性一堆設計patters建議。有時我不明白我爲什麼一直來到這個網站。 – 2013-11-04 18:32:07
親愛的問題關閉用戶：請告訴我們，我們應該在哪裏提問這樣的問題。 – guettli 2014-05-07 19:33:43
這裏是我覺得有用的東西http://www.codeproject.com/Articles/359654/important-database-designing-rules-which-I-fo#Rule2:-Breakyourdataintologicalpieces,makelifesimpler – mattymanme 2016-08-22 13:06:12