問題描述

為了避免數(shù)據(jù)庫一對多多對多的復(fù)雜關(guān)系，我對數(shù)據(jù)庫的設(shè)計是表里的字段都沒有外鍵，其關(guān)系使用setter和getter來手動關(guān)聯(lián)，但是程序?qū)懴聛砹?，功能是可以實現(xiàn)，但是發(fā)現(xiàn)要寫一大堆的getter與setter，很痛苦，還是說從一開始就不應(yīng)該這樣設(shè)計呢

問題解答

這樣設(shè)計很好啊，你只是缺一個數(shù)據(jù)庫抽象層，或者 ROM。

數(shù)據(jù)庫理論有個概念叫：CAP。

CAP理論是由 EricBrewer 教授提出的，在設(shè)計和部署分布式應(yīng)用的時候，存在三個核心的系統(tǒng)需求，這個三個需求之間存在一定的特殊關(guān)系。三個需求如下：

C: Consistency 一致性A: Availability 可用性P: Partition Tolerance分區(qū)容錯性

CAP理論的核心是：一個分布式系統(tǒng)不可能同時很好的滿足一致性，可用性和分區(qū)容錯性這三個需求，最多只能同時較好的滿足兩個。

而大部分 nosql 數(shù)據(jù)庫都在 C（一致性）上妥協(xié)了。

所以放棄外鍵是明智的。外鍵是為了保持所有的數(shù)據(jù)一致性，但是很多時候我們根本不需要數(shù)據(jù)是實時一致的，我們只需要保證最終一致性就可以了。

http://www.csdn.net/article/2...

http://duanple.blog.163.com/b...

1,現(xiàn)在互聯(lián)網(wǎng)基本不用外鍵.2,get set的問題可以試試Lombok

我們在實際應(yīng)用中一般外鍵都是用程序去控制的。不在數(shù)據(jù)庫層面。

第一，關(guān)系型數(shù)據(jù)庫的外鍵（此處特指映射關(guān)系）還是很有用的第二，外鍵（此處特指外鍵約束）是不應(yīng)該存在的。

現(xiàn)在用外鍵的應(yīng)用越來越少了。 在10年前還是挺多的。 主要是業(yè)務(wù)獨立的考慮吧。 喜歡把業(yè)務(wù)完全放在應(yīng)用端，數(shù)據(jù)庫只是用來持久化使用的。

十多年前開始工作的時候的一些項目數(shù)據(jù)庫，數(shù)據(jù)庫也參與到業(yè)務(wù)當(dāng)中，但是后期發(fā)現(xiàn)維護(hù)起來很痛苦。后來項目維護(hù)的時候，為了能應(yīng)對所有問題，不得不增加了數(shù)據(jù)庫專員。在項目總結(jié)中也提出這個問題了。數(shù)據(jù)庫專員的成本很高的。