以下是針對事務型資料庫設計經驗：
1.資料庫設計經驗之是否使用聯合主鍵？
個人傾向於少採用聯合主鍵。因為這樣會降低索引的效率，聯合主鍵一般都要用到至少乙個業務字段，往往是字串型的，而且理論上多字段的索引比單字段的索引要慢些。看上去似乎也不那麼清爽。
在實際的設計中，我盡量避免使用聯合主鍵，有些時候「不得不」使用聯合主鍵。
2.資料庫設計經驗之pk採用無意義的字段（邏輯主鍵）還是有意義的字段（業務主鍵）？
個人傾向於「邏輯主鍵」，理由是這樣設計出的資料庫模型結構清晰、關係脈絡清楚，往往更符合「第三正規化」（雖然不是故意的，呵呵）。而且更容易避開「聯合主鍵」，而且可以使用索引效率高的字段型別，比如int、long、number。缺點是用無意義的字段建立表間的關係，使跨表查詢增多，效率下降。（矛盾無處不在，前面剛說完可以提高效率，這裡馬上又降低效率）。「業務主鍵」可以提公升查詢編碼的簡潔度和效率。
個人使用實際狀況，總體來說「邏輯主鍵」比「業務主鍵」執行效率低，但不會低到無法滿足需求。採用「邏輯主鍵」比採用「業務主鍵」更利於資料庫模型的結構、關係清晰，也更便於維護。
對於分析型資料庫，如資料倉儲，千萬不要這樣做。
3.資料庫設計經驗不要使用多對多關係？
個人傾向於少使用多對多關係。這個問題其實不是資料庫設計的問題了，在資料庫設計中，多對多關係也僅僅存在於概念模型（e-r）階段，物理模型不在有多對多關係，實際資料庫中也不會有「多對多」關係。這是使用orm時的問題，比如使用hibernate，多對多關係有時會使編碼看起來靈活一些，代價是效率的明顯降低。
個人實際使用中，設計時基本不考慮多對多關係，但編碼時總會有小組成員使用一些多對多關係，自己建立多對多的orm，使自己編碼方便些，用在資料量小的地方，影響不大。大資料量，則「禁止使用」。
4.資料庫設計經驗之為每個表增加乙個state欄位？
我習慣在設計時給每個表設乙個state欄位，取值0或1，預設值為1，具體業務意義或操作上的意義可以自定義。可以作為乙個狀態控制字段，如查詢、更新、刪除條件，單據是否有效（業務單據對應的表會有業務意義上的「有/無效」或「狀態」字段，這種情況下，我還是會再加乙個state欄位），甚至僅僅是控制一條資料是否「有效」（有效的意義你自己定）。在資料遷移（如轉入分析用的資料庫）時也可能會發揮作用。
5.資料庫設計經驗之為每個表設定一些備用字段？
沒辦法，我總是設計不出「完美」的資料表，給每個表加幾個備用字段（我一般用字串型，隨你）可以應付「不時之需」，尤其是需要長期維護的、業務可能有臨時性變動的系統。
6.資料庫設計經驗之盡量不要在乙個表中存入其關聯表的字段？
建議不存！這樣做確實可以提高查詢效率，但在乙個有很多表，並且關聯表多的情況下，很難保持資料的一致性！資料庫結構也比較糟糕。而且不存，也不會使效率十分低下。
7.資料庫設計經驗之不要去直接修改資料庫？
個人認為這點很重要，當需要修改時，應該先去修改模型，然後同步物理資料庫，尤其是團隊開發，否則要多做更多的事情來搞定，也可能會引入更多的錯誤。
以上就是對事務型資料庫設計經驗的總結。
針對事務型資料庫設計小結
1.是否使用聯合主鍵？個人傾向於少採用聯合主鍵。因為這樣會降低索引的效率，聯合主鍵一般都要用到至少乙個業務字段，往往是字串型的，而且理論上多字段的索引比單字段的索引要慢些。看上去似乎也不那麼清爽。在實際的設計中，我盡量避免使用聯合主鍵，有些時候 不得不 使用聯合主鍵。2.pk採用無意義的字段 邏輯主...
關係型資料庫設計
1.五級正規化 一般滿足 即可 第一正規化的定義 如果乙個表中沒有重複組 即行與列的交叉點上只有乙個值，而不是一組值，例如 姓名 性別 字段，但 愛好 欄位不符合1nf 且定義了關鍵字 所有非關鍵屬性都依賴於關鍵字，則這個表屬於第一正規化 常記成1nf 第二正規化的定義 如果乙個表屬於1nf，且不包...
資料庫設計和事務
資料庫設計 資料庫設計的乙個主要目的是消除資料庫的冗餘。為此要使用標準化 normalization 技術 資料庫冗餘 如資料庫表中的多行資料有重複出現的情況，這回導致兩個問題 1 每次查詢時，都必須一次又一次的輸入同一查詢條件 2 也是更為重要的，如果任何乙個資料發生了變化，就必須在多個位置上進行...