在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

鍍金池/ 問答/Java  UI/ Java Spring開發(fā)一次性將對象的所有子對象從數(shù)據(jù)庫中拉取出來是否合理?

Java Spring開發(fā)一次性將對象的所有子對象從數(shù)據(jù)庫中拉取出來是否合理?

比如:
有一個Company公司類,
Company公司類中有一個List<User>用戶列表,
User類中有一個Address類用于存放用戶的若干地址。

那么,現(xiàn)在有這樣一種系統(tǒng)設(shè)計思路:
傳一個公司id給后端,則在后端直接構(gòu)造出該公司實例以及其下所有用戶對象以及各個用戶對象下的所有地址信息。
最后生成的對象就像這樣:

Company{
    User{
        Address{}
        Address{}
    }
    User{
        Address{}
    }
    User{
        Address{}
        Address{}
        Address{}
    }
}

這樣設(shè)計有一個好處是你要使用的時候可以直接Company.User[i].Address[j]來調(diào)用你想用的信息。但是在構(gòu)造它的時候會耗費大量的數(shù)據(jù)庫查詢性能并且可能存在數(shù)據(jù)不同步問題。

想問下大家,這種系統(tǒng)設(shè)計思路,是否合理?

回答
編輯回答
心夠野

你好,我最近在寫一個java的orm框架,剛好也涉及到這方面的問題。我在之前設(shè)計的時候,也是考慮的獲取數(shù)據(jù)庫數(shù)據(jù)時一次性全部獲取出來,但我設(shè)計的時候遇到的如下問題:

1. 代碼復(fù)雜

考慮如下對象:

class Province{
  private long id;
  private City[] cities;
}

class City{
  private long id;
  private Country[] country;
}

在映射關(guān)系上,one-one映射和one-many映射比較好處理,但是如果有類似這樣多個映射關(guān)系 Province-->City-->Country 而且又包含集合的時候,保存時在設(shè)計上是非常復(fù)雜的.我有查看過nutzDAO的文檔,它的實現(xiàn)方式其實是將數(shù)組中的對象壓入隊列中作為單個對象插入,然而毫無疑問,如果插入大量數(shù)據(jù),這樣的性能肯定很底下.我在設(shè)計orm框架時就是覺得對于復(fù)雜的映射關(guān)系,不僅代碼復(fù)雜而且性能很難保證,所以決定棄用這種一次取出來和一次性保存的方式。
所以我最后設(shè)計的思想如下代碼:

class Province{
  private long id;
}

class City{
  private long id;
  private long provinceId;
}

將外鍵僅僅當作普通的成員變量,在查詢時將外鍵作為條件查詢即可.保存時,先保存Province變量,獲取到id后,再插入City變量,設(shè)置他們的proviceId為獲取到的id即可.簡化設(shè)計也提高性能.

2. 性能

誠如你的問題所說,實際上很多時候我們并不需要提取相關(guān)的所有數(shù)據(jù),在性能和代碼復(fù)雜性做平衡考慮,實際上查詢數(shù)據(jù)時,單個表查詢,邏輯最清楚,程序員開發(fā)時也不容易出錯,可以根據(jù)自己的需要做定制.特別是對于企業(yè)項目,多個實體互相關(guān)聯(lián),如果一次性提取出來,可能數(shù)據(jù)量比較龐大,而程序員獲取只需要其中的一小部分數(shù)據(jù),這樣在性能上得不償失.

總結(jié)

總結(jié)一下我的答案就是,為了簡單和性能著想,一次性取出所有數(shù)據(jù)(一次性保存實體所有相關(guān)實體數(shù)據(jù))增加代碼復(fù)雜性又增加了性能負擔(dān)。

另外本人最近參考了市面的一些orm框架,自己編寫了一款還處于快照期(API不穩(wěn)定)的Java開源ORM框架,限于社區(qū)規(guī)范,如果感興趣的可以私信本人交流哦。

另外再多提一嘴,本人最近看了國內(nèi)的幾個技術(shù)相關(guān)的社區(qū),感覺很多社區(qū)技術(shù)氛圍不是很好,披著程序員交流,技術(shù)交流的皮,但是幾乎都是各種灌水,交流,征婚,文風(fēng)跟貼吧簡直沒有區(qū)別. 更讓我覺得有些氣憤又有一些羞恥的是,有一些中國"開發(fā)者"在github上開源項目的的外國人(我不知道有沒有針對中國開發(fā)者github項目)的issue區(qū)發(fā)一些毫無意義的灌水帖,而且評論有十幾樓,完全中國式的文風(fēng)(例如有人評論"six,six,six","Please sit down, Mr. Chen","double click! six six six"),雖然底下也有幾位中國開發(fā)者為這樣的行為道歉,但看了這樣的行為,同作為國人,還是感覺到氣氛和羞恥的.
關(guān)注到segmentFault是剛好最近看到有一篇主題帖,講的就是因為用戶量增加,為了規(guī)范回答,會提出更加嚴格的提問規(guī)范.我知道對于在用戶量和技術(shù)氛圍上做平衡其實是一件很難的事情(根據(jù)比例原則,除非中國人的整體素質(zhì)大幅提升),因此非常希望segmentFault的管理團隊能夠盡力維持好整個社區(qū)的技術(shù)氛圍,我也決定將扎根segmentFault社區(qū),回答一些我力所能及的問題.

2017年8月17日 22:07
編輯回答
詆毀你

如果這些數(shù)據(jù)都需要用到,可以全部加載出來。否則就按需加載,用到的時候再加載。

2018年8月12日 10:56
編輯回答
孤星

數(shù)據(jù)量不大的情況下可以這么做

2018年4月9日 13:28
編輯回答
護她命

這樣的數(shù)據(jù)結(jié)構(gòu)只是一個外部的接口,后端不一定是一次性全都從數(shù)據(jù)庫里讀出來,還可以使用懶加載的方式,具體懶到什么程度還可以調(diào)整

2017年7月20日 16:52
編輯回答
喜歡你

題主這么存儲想用來解決什么業(yè)務(wù),Company.User[i].Address[j]這種方式,感覺也就是用來便利,并沒有節(jié)省查詢的效率呀,單純是為了便利列表的話,除非需求很頻繁,能節(jié)省構(gòu)建。其他情況,沒看出什么效率上的優(yōu)勢。

2017年1月14日 15:39