問題描述

為了避免數據庫一對多多對多的復雜關系，我對數據庫的設計是表里的字段都沒有外鍵，其關系使用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年前還是挺多的。 主要是業務獨立的考慮吧。 喜歡把業務完全放在應用端，數據庫只是用來持久化使用的。

十多年前開始工作的時候的一些項目數據庫，數據庫也參與到業務當中，但是后期發現維護起來很痛苦。后來項目維護的時候，為了能應對所有問題，不得不增加了數據庫專員。在項目總結中也提出這個問題了。數據庫專員的成本很高的。