資料庫的設計原則：關聯還是不關聯？
設計**資料庫（確定使用hibernate）的過程中，時常會有爭論，爭論的焦點主要還是集中在表與表之間的關聯上面：
有的傾向於去掉表與表之間的任何關聯；有的拿完整性說話，必須保留所有的關聯性。
觀點1：我傾向於去掉所有的關聯，為了開發的方便。然後寫**的時候自己留意完整性的問題。
觀點2：
如果不採用外來鍵關聯的話，很多字段勢必得集中在乙個表裡面，從而造成資料冗餘。根據領域模型驅動的方式設計資料庫表結構，領域模型中的每乙個物件只有一項職責，所以物件中的資料項不存在傳遞依賴，這種思路的資料庫表結構設計從一開始即滿足第三正規化：乙個表應滿足第二正規化，且屬性間不存在傳遞依賴。
如果是小專案的話，為了開發方便一點而不關聯都問題不大，但要是大專案的話，感覺還是遵守規範的好
觀點3：
看你做什麼樣乙個壓力的系統了， 如果的系統是每秒要上萬個交易的話， 親愛的， 我建議你少用join吧。少於１ｗ／ｓ的系統， 無所謂， 怎麼搞都一樣的。 完整性比任何都重要， 在壓力過高的時候， 妥協而已！ 我的策略就是對於主壓力的表， 一般來說， 系統中總是有幾個焦點表的， 資料訪問壓力高， 讀寫密集的， 這個幾個表好好設計， 不要關聯，把讀寫操作讓能力好的， 經驗豐富的程式設計師去做封裝ｄａｏ ａｐｉ。 其他的小表， 要做關聯， 防止程式設計師出問題。我們現在這個做了4年還在做，200m，50多萬行的專案現在是傾向於完全不建關聯了，新的資料模型一律不考慮關聯
觀點4：
具體情況具體分析
業務表 我認為關聯要好
而有一些歷史資訊比如日誌什麼的，我基本都不關聯，而且最大冗餘~
我的觀點：
db方面經驗不足，暫不發表意見。
資料庫的自身關聯
查詢出每個雇員的編號，姓名及其上級領導的編號，姓名 select e.empno eno,e.ename ename,m.empnomno,m.ename mname from emp e,emp m where e.mgr m.empno 查詢出在1981年僱擁的全部雇員的編號，姓名，僱擁日期 按...
關聯表查詢資料庫
1.呼叫方法 this getrelationlist m map,bd prefix.deal as d left join db prefix.user as u on d.user id u.id d.u.site id d.id map指的是查詢條件陣列 2.實現函式 protected f...
資料庫關聯查詢
使用者授權，我們涉及到了三個物件 1 使用者名稱root 2 密碼 3 主機localhost 建立名字為qq的使用者 create user qq localhost 建立名字為anan使用者並新增密碼 create user anan localhost identified by 123 建立...