4

我正試圖將我的頭圍繞Google AppEngine中的實體組。我通常會理解他們,但是由於聽起來您無法在創建對象後更改關係,並且我有大量數據遷移要做,所以我想在第一次嘗試做到這一點。Google Appengine:這是一組好的實體組嗎?

我正在製作一個藝術網站,成員可以定期註冊成爲常規會員或少數非多態實體「類型」(藝術家,地點,組織,藝術家代表等)。例如藝術家可以有藝術作品,藝術作品又可以有其他關係(畫廊,媒體等)。所有這些事情都通過引用連接,我知道你不需要實體組只做引用。然而,一些參考文獻需要存在,這就是爲什麼我正在尋找實體組。

來自文檔: 「對於實體組來說,一個好的經驗法則是它們應該大約是單個用戶的數據量或更小的數據量。」

這就是說,我有一對希望是/沒有問題。

問題0:我收集你並不需要實體組來做事務。但是,由於實體組存儲在大表的相同區域,這有助於減少一致性問題和競爭條件。這是否公平地看待實體組和事務?

問題1:當保存一個子實體時,是否隱式訪問/保存了任何父對象?即如果我建立了一個具有路徑成員/藝術家/藝術作品的實體組,如果我保存了作品對象,會員和藝術家對象是否被更新/訪問?我想不會,但我只是確信。

問題2:如果問題1的答案是肯定的,那麼訪問/更新只會沿着路徑行進而不會影響其他孩子。即如果我更新圖稿,則不更新會員的其他圖稿。

問題3:假設當用戶註冊並且只有用戶將更新其成員和關聯的賬戶類型實體時,會員及其關聯的賬戶類型實體是非常重要的,那麼將這些在實體組中一起?

即會員/藝術家,會員/組織,會員/場所。

同樣,假設只有用戶能夠更新藝術品實體,那麼是否有意義也包含這些實體?注意:媒體/圖庫/等是藝術作品的參考,可能與許多藝術作品有關,而不僅僅是用戶擁有的作品(即多對多關係)。

如果按照我懷疑的方式工作(即Q1/Q2爲「否」),那麼將實體組中的所有用戶位都置於同一個BigTable區域中是有意義的。但是,將圖形添加到實體組似乎可能會違反「保持它小」的原則,並且誠實地說,可能不需要在交易中除了在用戶上傳圖形圖像時節省帶寬/重新搜索之外。

有什麼想法?我接近實體組錯了嗎?

回答

2
  • 0:您確實需要多個實體
  • 之間進行交易的實體組
  • 1:修改/訪問兒童修改/訪問父
  • 2:N/A
  • 3:聲音合理。我的感覺是,除非你需要他們之間的交易,否則不應該使用實體組。

沒有必要將藝術品作爲兒童出於許可目的。但是如果你需要對它們進行交易修改(包括例如創建和刪除),它可能會更好。例如:如果您刪除某個帳戶,則會刪除該用戶實體,但在刪除該子項之前,您會收到DeadlineExceeded或服務器崩潰。現在你有一個孤兒藝術品。如果您的藝術家的作品超過1,000件,則必須批量刪除。

祝你好運!

+0

謝謝Jhs!我認爲這給了我設置遷移的良好開端。 – 2010-01-31 16:46:31

+0

如何批量刪除? – corydoras 2010-07-27 08:41:43

相關問題