2011-04-17 128 views
0

我正處於設計非常大型系統(其企業級銷售點系統)的早期階段。因爲你們有些人知道這些事情的數據模型會變得非常複雜。我想在谷歌應用引擎上運行這個東西,因爲我想把更多的資源用於開發軟件,而不是構建和維護基礎架構。本着這種精神,我在GAE和DataStore上做了大量的閱讀工作。即時通訊一個老同學的關係型數據庫建模和香港專業教育學院的一個無模式數據庫是什麼見過幾個不同的概念,我認爲香港專業教育學院想出了數據存儲是什麼,但我想確保我有它正確瞭解Google App Engine數據存儲

所以,如果即時通訊的權利GAE是基於表格的系統。所以如果我創建一個Java實體

class user 
public string firstname 
public string lastname 

並部署它,「表」用戶自動創建並運行。然後在次後發佈,如果我修改類用戶

並部署它,「表」用戶自動更新與新字段。

現在,在相關數據中,據我所知,它非常類似於一些大型複雜系統,如SAP,其中數據實際上非常有組織,但由於卷的參考完整性是應用程序的一個功能,而不是數據庫引擎。所以,我有一些代碼看起來像這樣

class user 
public long id 
public string firstname 
public string lastname 

class phone 
public string phonenumber 
public user userentity 

,並從頭拉起電話號碼的用戶,而不是

select phone from phone inner join user as phone.userentity = user where user.id = 5 
(lay off i know the syntax is incorrect but you get the point) 

我會做類似

select user from user where user.id = 5 
then 
select phone from phone where phone.userentity = user 

和這將檢索用戶的所有電話號碼。

所以,據我所知,它不是一個如何思考結構化數據和組織數據的巨大變化,因爲它是如何訪問它的一個重大變化。我使用代碼手動加入,而不是與數據庫引擎自動加入。超越它的相同。我是對的還是我無能爲力?

+0

嗯......我的客戶對存儲在其他公司的數據庫他們的銷售數據很矜持。 – 2011-04-17 22:10:55

回答

5

根本沒有表格。如果您只讓某些用戶名和姓,然後再添加addDate,那麼您的原始實體仍然沒有addDate屬性。以任何方式都沒有用戶實體連接。它們不在用戶的表格中。

您可以訪問您寫入數據庫的名稱爲「User」的所有對象,因爲appengine會保留所有具有每個名稱的對象的大長列表(索引)。所以,你放在那裏的名稱(種類)爲「User」的任何對象都會在這個列表中獲得一個條目。稍後,您可以閱讀該索引以獲取每個對象的位置,並使用這些位置(鍵)來獲取對象。他們不在桌子上,他們只是在四處漂泊。其中一些有一些共同的特性,但這是巧合,而不是要求。

如果你想要獲取所有具有特定名稱的用戶對象(從用戶名中選擇*,其中firstname =「Joe」),那麼你必須保持另一個大的長索引鍵。該索引具有firstname屬性以及每行上的實體的關鍵字。稍後,您可以掃描索引firstname,獲取所有密鑰,然後查找使用這些密鑰存儲的實際實體。所有這些實體將擁有firstname屬性(因爲您不會在firstname索引中輸入沒有firstname屬性的實體),但它們可能沒有任何其他共同字段,因爲它們不在執行任何數據的表中結構。

這些併發症會影響數據訪問的方式,而且會影響事務,如事務和複雜查詢。基本上,您不必過多地改變自己的想法,但在規劃數據結構之前,您一定要明白索引和事務是如何工作的。它是而不是對於在開始之前您沒有想到的額外查詢來說,總是很簡單,而且維護這些索引的成本非常高昂,所以越少越好。

+0

啊,好的。那麼第二部分呢,分層數據呢?如果我理解你說的正確,我會按照上面描述的方式訪問分層數據。獲取有關用戶的密鑰,然後查詢該密鑰的電話號碼實體。正確? – scphantm 2011-04-17 22:21:36

+0

是的,這是正確的,雖然你應該直接進入密鑰,而不是查詢它(它在索引中查找,然後得到它)。您也可以創建直接指向「父」對象(保存查找)的分層鍵,但您需要了解「實體組」及其限制纔能有效使用它們。 – 2011-04-18 00:35:58

相關問題