簡單的值列表GAE python數據庫對象設計

我對數據庫對象設計非常陌生，所以請原諒我的問題中的任何古怪。基本上，我使用Google AppEngine（Python）並構造一個對象來跟蹤用戶信息。其中一項數據是40個成就得分。我是否在User對象中爲此列出了整數列表？或者我用我的用戶ID，成就指數（0-39）和得分製作一個單獨的實體，然後做一個查詢來抓取這40個項目，每次我總想獲取用戶數據？簡單的值列表GAE python數據庫對象設計

後一種方法似乎更傾向於我的面向對象，當然，如果我將它擴展到40個以上成就的分數以上，那當然會更好。但是，考慮到我可能無法擴展它，我是否應該考慮在我的用戶數據中做一個簡單的40個整數列表？然後，我會放棄做一個查詢，得到排序的成就列表，從每一個閱讀得分只是爲了處理一個響應等。

正在做這種後一種方法就是這樣一個普遍的做法，揮手甚至不值得在思考方面打擊睫毛可能會更昂貴或複雜的處理明智？

來源

2010-02-28 Joey

我喜歡保持的40個int是清單的簡單的想法，但你不能強迫它進到App Engine的現有User類，其佈局是由GAE的API來確定（但不包括那些40 int S）。因此，該列表將不可避免地需要生活在單獨的實體中（即，單獨模型的每個實例）。

來源

2010-03-01 00:06:51

我沒有意識到有一個用戶類。我的意思是我有我自己的MyUser實體，我可以聲明一個40個整數的列表。我一直在尋找的是，使用40個整數通常是一個非常無關緊要的優化，而不是創建一個單獨的實體類型來包含該數據，然後必須在每次想要獲取特定用戶的信息時查詢這些數據。感謝您的回覆。我會跟隨這種迴應，想知道在什麼時候最好分解成一個單獨的實體，或者在我的MyUser類中保留多個「40件事情」列表以避免查詢。 – Joey 2010-03-01 06:09:16

@Joey，查詢的成本是一個常數加上一個與實體大小成比例的術語;因此，存儲（並且每次都不可避免地提取）您不總需要的數據會導致性能成本（較大的實體）分裂，以及增加（較少的查詢），所以「在什麼時間點」一個或另一個設計更好取決於在主要實體的每次提取時將或不需要這樣的額外數據的可能性。 – 2010-03-01 15:25:51

簡單的值列表GAE python數據庫對象設計

回答

相關問題