為了避免資料庫一對多多對多的複雜關係，我對資料庫的設計是表裡的欄位都沒有外鍵，其關係使用setter和getter來手動關聯，但是程式寫下來了，功能是可以實現，但是發現要寫一大堆的getter與setter，很痛苦，還是說從一開始就不應該這樣設計呢
這樣設計很好啊，你只是缺少一個資料庫抽象層，或是 ROM。
資料庫理論有個概念叫做：CAP。
CAP理論是由 EricBrewer 教授提出的，在設計和部署分散式應用的時候，有三個核心的系統需求，而這個三個需求之間存在著一定的特殊關係。三個需求如下：
C: Consistency 一致性A: Availability 可用性P: Partition Tolerance分區容錯性
CAP理論的核心是：一個分散式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，最多只能同時較好的滿足兩個。
而大部分 nosql 資料庫都在 C（一致性）上妥協了。
所以放棄外鍵是明智的。外鍵是為了保持所有的資料一致性，但是很多時候我們根本不需要資料是即時一致的，我們只需要保證最終一致性就可以了。
http://www.csdn.net/article/2...
http://duanple.blog.163.com/b...
1,現在網路基本上不用外鍵.2,get set的問題可以試試Lombok
我們在實際應用中一般外鍵都是用程式去控制的。不在資料庫層面。
第一，關係型資料庫的外鍵（此處特指映射關係）還是很有用的第二，外鍵（此處特指外鍵約束）是不應該存在的。
現在用外鍵的應用越來越少了。 在10年前還挺多的。 主要是業務獨立的考慮吧。 喜歡把業務完全放在應用端，資料庫只是用來持久化使用的。
十多年前開始工作的時候的一些專案資料庫，資料庫也參與到業務當中，但是後期發現維護起來很痛苦。後來專案維護的時候，為了能應付所有問題，只好增加了資料庫專員。在專案總結中也提出這個問題了。資料庫專員的成本很高的。
這樣設計很好啊，你只是缺少一個資料庫抽象層，或是 ROM。
資料庫理論有個概念叫做：CAP。
CAP理論是由 EricBrewer 教授提出的，在設計和部署分散式應用的時候，有三個核心的系統需求，而這個三個需求之間存在著一定的特殊關係。三個需求如下：
C: Consistency 一致性
A: Availability 可用性
P: Partition Tolerance分區容錯性
CAP理論的核心是：一個分散式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，最多只能同時較好的滿足兩個。
而大部分 nosql 資料庫都在 C（一致性）上妥協了。
所以放棄外鍵是明智的。外鍵是為了保持所有的資料一致性，但是很多時候我們根本不需要資料是即時一致的，我們只需要保證最終一致性就可以了。
http://www.csdn.net/article/2...
http://duanple.blog.163.com/b...
1,現在網路基本上不用外鍵.
2,get set的問題可以試試Lombok
我們在實際應用中一般外鍵都是用程式去控制的。不在資料庫層面。
第一，關係型資料庫的外鍵（此處特指映射關係）還是很有用的
第二，外鍵（此處特指外鍵約束）是不應該存在的。
現在用外鍵的應用越來越少了。 在10年前還挺多的。 主要是業務獨立的考慮吧。 喜歡把業務完全放在應用端，資料庫只是用來持久化使用的。
十多年前開始工作的時候的一些專案資料庫，資料庫也參與到業務當中，但是後期發現維護起來很痛苦。後來專案維護的時候，為了能應付所有問題，只好增加了資料庫專員。在專案總結中也提出這個問題了。資料庫專員的成本很高的。