用於存儲來自外部網站的用戶數據的數據庫設計模式

我正在研究一個應用程序，該程序允許用戶通過facebook或twitter進行註冊，我希望能夠從這些網站使用他們的個人數據，並想知道我應該如何存儲它。這裏是我想出迄今：用於存儲來自外部網站的用戶數據的數據庫設計模式

enter image description here

的user表將存儲應該是目前不論如何，用戶註冊信息，如first_name。

user_property該表將工作爲key-value緩存和存儲信息的特定於facebook或twitter（由origin字段表示）。我將存儲可作爲API調用或SQL個別查詢的一部分的屬性，如用戶的facebook id，我將存儲JSON格式的其他API調用的調用結果，例如用戶的facebook friends。

這樣：

我有共同的信息user表，使用一個單一SELECT我可以得到用戶的一些基本有用的信息
我有一些額外的屬性從facebook/twitter（例如，用戶ID來）單獨存儲，我仍然可以用JOIN查找user和user_property。
我可以檢索過於昂貴的存儲標準化的信息（例如，創建一個表來存儲朋友的朋友，並且每個朋友有一個表項）仍然有JOIN，位於user和user_property之間。

這裏是什麼我不知道現在：

Q1：難道這是一個有點可持續的數據庫設計還是我得到它錯了，會碰到一些問題，如果是這樣，哪個？ Q2：當存儲頻繁變化的信息（例如朋友/追隨者列表）時，你如何保持信息是最新的（你是否將信息存儲在數據庫中？如果是的話，你用什麼標準/觸發來決定何時再次提取信息）？

來源

2012-11-04 Max

您應該仔細閱讀您正在考慮使用的API的服務條款。他們中的大多數不允許您永久存儲通過其API檢索的任何數據（僅緩存一小段時間）。 –

感謝您的信息。我猜這部分答案是'Q2'，因爲如果服務條款說'你只允許緩存24小時'，那麼通過每隔24小時提取一次信息，我會遵守這些條款。 – Max

此外，反引號僅用於格式化代碼（如變量或函數名稱）。當您將它用於各種其他術語時，它會讓您感到困惑...... –

您的設計具有EAV架構（實體 - 屬性 - 值）的大多數（壞）屬性。在這個問題上尋找Wikipedia，並環顧這個網站。

EAV最不可持續的設計決定是（恕我直言），在一開始這似乎很好地擴展。但是一旦數據增長，你就會以高速撞擊混凝土牆。這是因爲爲了加載數據一個用戶該數據庫必須用隨機訪問觸摸巨大的部分物理表。當數據增長並且經常變化時，調整數據庫以將一個用戶的user_property行保留在相鄰頁面中是一項艱鉅的任務。

來源

2012-11-04 23:35:40

感謝'A.H.'：您會提出什麼替代設計？ – Max

@ user359650：我唯一的建議是非常通用的：嘗試查找結構，嘗試查找屬於彼此的屬性，將它們存儲在一個元組中。另外：要清楚和誠實地告訴你自己真正需要什麼數據以及如何處理數據。這將篩選出大部分的「哦，我*可以*在那裏讀取數據xy，所以我*將*讀取並存儲它，因爲我可能會使用它*以某種方式*以後」cruft。相反問：「我現在想做abc *，我需要這些數據。」 –

我可以清楚地感受到你在這裏觸及的問題：我玩過Facebook的'API'，並且想：「哇，我可以得到一些關於我的用戶的大量數據」，風險肯定是我過度設計我將最終不會使用數據。 – Max

用於存儲來自外部網站的用戶數據的數據庫設計模式

回答

相關問題