以下是針對事務(wù)型數(shù)據(jù)庫：
1.是否使用聯(lián)合主鍵？個人傾向于少采用聯(lián)合主鍵。因為這樣會降低索引的效率，聯(lián)合主鍵一般都要用到至少一個業(yè)務(wù)字段，往往是字符串型的，而且理論上多字段的索引比單字段的索引要慢些。看上去似乎也不那么清爽。
在實際的設(shè)計中，我盡量避免使用聯(lián)合主鍵，有些時候“不得不”使用聯(lián)合主鍵。

2.PK采用無意義的字段（邏輯主鍵）還是有意義的字段（業(yè)務(wù)主鍵）？個人傾向于“邏輯主鍵”，理由是這樣設(shè)計出的數(shù)據(jù)庫模型結(jié)構(gòu)清晰、關(guān)系脈絡(luò)清楚，往往更符合“第三范式”（雖然不是故意的，呵呵）。而且更容易避開“聯(lián)合主鍵”，而且可以使用索引效率高的字段類型，比如int、long、number。缺點是用無意義的字段建立表間的關(guān)系，使跨表查詢增多，效率下降。（矛盾無處不在，前面剛說完可以提高效率，這里馬上又降低效率）。“業(yè)務(wù)主鍵”可以提升查詢編碼的簡潔度和效率。
個人使用實際狀況，總體來說“邏輯主鍵”比“業(yè)務(wù)主鍵”執(zhí)行效率低，但不會低到無法滿足需求。采用“邏輯主鍵”比采用“業(yè)務(wù)主鍵”更利于數(shù)據(jù)庫模型的結(jié)構(gòu)、關(guān)系清晰，也更便于維護。
對于分析型數(shù)據(jù)庫，如數(shù)據(jù)倉庫，千萬不要這樣做。

3.不要使用多對多關(guān)系？個人傾向于少使用多對多關(guān)系。這個問題其實不是數(shù)據(jù)庫設(shè)計的問題了，在數(shù)據(jù)庫設(shè)計中，多對多關(guān)系也僅僅存在于概念模型（E-R）階段，物理模型不在有多對多關(guān)系，實際數(shù)據(jù)庫中也不會有“多對多”關(guān)系。這是使用ORM時的問題，比如使用Hibernate，多對多關(guān)系有時會使編碼看起來靈活一些，代價是效率的明顯降低。
個人實際使用中，設(shè)計時基本不考慮多對多關(guān)系，但編碼時總會有小組成員使用一些多對多關(guān)系，自己建立多對多的ORM，使自己編碼方便些，用在數(shù)據(jù)量小的地方，影響不大。大數(shù)據(jù)量，則“禁止使用”。

4.為每個表增加一個state字段？我習(xí)慣在設(shè)計時給每個表設(shè)一個state字段，取值0或1，默認值為1，具體業(yè)務(wù)意義或操作上的意義可以自定義。可以作為一個狀態(tài)控制字段，如查詢、更新、刪除條件，單據(jù)是否有效（業(yè)務(wù)單據(jù)對應(yīng)的表會有業(yè)務(wù)意義上的“有/無效”或“狀態(tài)”字段，這種情況下，我還是會再加一個state字段），甚至僅僅是控制一條數(shù)據(jù)是否“有效”（有效的意義你自己定）。在數(shù)據(jù)遷移（如轉(zhuǎn)入分析用的數(shù)據(jù)庫）時也可能會發(fā)揮作用。

5.為每個表設(shè)置一些備用字段？沒辦法，我總是設(shè)計不出“完美”的數(shù)據(jù)表，給每個表加幾個備用字段（我一般用字符串型，隨你）可以應(yīng)付“不時之需”，尤其是需要長期維護的、業(yè)務(wù)可能有臨時性變動的系統(tǒng)。

6.盡量不要在一個表中存入其關(guān)聯(lián)表的字段？建議不存！這樣做確實可以提高查詢效率，但在一個有很多表，并且關(guān)聯(lián)表多的情況下，很難保持數(shù)據(jù)的一致性！數(shù)據(jù)庫結(jié)構(gòu)也比較糟糕。而且不存，也不會使效率十分低下。

7.不要去直接修改數(shù)據(jù)庫？個人認為這點很重要，當(dāng)需要修改時，應(yīng)該先去修改模型，然后同步物理數(shù)據(jù)庫，尤其是團隊開發(fā)，否則要多做更多的事情來搞定，也可能會引入更多的錯誤。