是否可以在Google App Engine中保留標準化模型？

直接指向這一點，是否可以在Google App Engine數據存儲區中保留一個標準化的二維模型，其中每個關係本身就是一種類型，其實體是關係的實例？是否可以在Google App Engine中保留標準化模型？

我已經知道數據存儲（其底層的Bigtable技術）的工作原理不同於RDBM系統，但我的問題是：是什麼阻止一個從仍然在關係的方式奠定了他們的模型（與從所有的優點理論和規劃的角度）在數據存儲區內？

一個例子來澄清。我不能仍然計劃以下類型的實體：

人（姓名：STR，公司：公司）
公司（名稱：STR）
項目（注：文）
PersonProjects（人：人，項目簡介：項目）

引用其他實體的屬性（如Person.Company，PersonProjects.Project）將存儲這些實體的標識。主要缺點（如果有的話）是什麼，性能明智？請注意，我可以進一步標準化模型，例如，爲PersonName，CompanyName等引入新類型，但我決定在這裏保持它們引用的相同類型的一個值屬性。我記得前段時間看過I/O系列（由Google製作）的視頻，其中使用了規範化技術來防止某種類型的實體太大，即具有太多屬性（問題實際上涉及爆炸索引）。計劃種類中的一個屬性作爲一種新類型被「分離」，只是在通過代碼後才被擴展。

那麼，我還不能爲所有的一種屬性做到這一點嗎？除了增加客戶端（或服務器端）工作（需要獲取「設置」用於檢索的對象）之外，我看不到任何主要問題。那麼，切換到「基於實體」的模型是否真的有必要？我們難道不能通過種類和實體來模擬關係嗎？

我希望我已經清楚了。

來源

2013-07-09 atava

您可以，但您通常需要爲了性能原因進行組合。當你需要多對多關係時，我使用中間實體。 –

感謝您的回覆。但是，你暗示的性能問題究竟是什麼？這基本上是我需要知道的。 – atava

當事情開始需要很長時間時，你會知道它。記住你不能做連接。因此，任何想要通過依賴於關係另一端的值的查詢來檢索的任何東西都會變得非常昂貴，如果您需要一個2級別的值，那麼它將花費很大。剖析您的應用程序，您將更清楚您需要優化的內容。在你的問題太過開放的時刻，正確的答案取決於你在做什麼。 –

沒有什麼能阻止你在數據存儲中規範你的模型。問題是Datastore的查詢語言非常有限：僅在一個屬性上進行不等式過濾，沒有多類查詢，沒有JOIN等。這迫使您根據訪問模式組織數據：面向訪問的建模。這通常會迫使您將數據存儲在不合邏輯的地方，以便快速獲取數據（=最小的數據庫操作集）。

此外，事務處理非常有限，迫使您以某種方式組織數據（實體組）。或者如果您使用XG交易，那麼您每次交易將被限制爲25個實體。

另請注意，SQL RDBM中通常沒有DB強制的參照完整性。

來源

2013-07-09 12:42:15

迄今爲止我收到的反饋使我確信，雖然可能，但整個關係類模型不適用對於數據存儲區，就像現在一樣。是的，所有這些都是由於缺少內置的查詢功能，如JOIN等（同樣由於對象在Bigtable中存儲和檢索的方式），需要依賴多個查詢來「構建」單個標準化對象領域。（參考完整性並不是什麼大問題，因爲我已經應對了代碼方面的問題，並且引擎已經呈現爲「鬆散」了。）感謝您的回覆！ – atava

是否可以在Google App Engine中保留標準化模型？

回答

相關問題