1
我的Android應用程序與對話MySQL後端使用PHP API。該應用程序允許讀者關注不同的作者,並在他們關注的作者之一收到通知後提交文章。使用MYSQL和PHP的通知系統
現在我正在通過爲每個作者的每個追隨者存儲一條新記錄來做到這一點。即:如果具有1000個關注者的作者提交了一篇文章,則會添加1000個新行,其中seen
列設置爲FALSE
。
現在,當移動應用程序請求看不見的通知時,我只能顯示那些記錄,將seen
設置爲TRUE
。
但是,這有些困難。例如,一羣擁有300k +追隨者的作者將創建大量的行。
這僅僅是這樣的系統的成本?還是有更高效的方式來處理這個,也許是從應用程序的一方?
Table : posts (Only the relevant columns)
-------------
id : INT(10) PK,NN,AI
author_id : INT(10) NN,UN
Table : followers
-----------------
id : INT(10) PK,NN,AI
author_id : INT(10) NN,UN
user_id : INT(10) NN,UN
Table : notifications
---------------------
id : INT(10) PK,NN,AI
user_id : INT(10) NN,UN
author_id : INT(10) NN,UN
seen : VARCHAR(1) NN
幾個表格註釋:
- 每一個用戶跟隨作者的時候,一個新行的
followers
表與讀者的user_id
創建的,而人的author_id
所預訂至。任何點的總行數將等於所有用戶的跟隨者總數。 - 當作者提交帖子時,會爲
notifications
表中的每個關注者創建一個新行,其中seen
列設置爲FALSE
。該應用程序然後發送另一個電話,以標記他們看到。這項工作是否會持續增加大量的數據? - 當應用程序請求通知時,將檢索
notifications
表中與當前用戶有關的所有不可見行。
這是我嘗試的第一件事,但我試圖避免宣佈在我上次檢查之前所做的所有帖子都被讀取。它造成了一個值得解決的問題,因爲上述解決方案的額外開銷。有什麼辦法可以克服嗎? –
當然,但他們還有很多工作 - 他們基本上是兩者的混合體。這裏的折衷是準確性,數據量和代碼的複雜性。您也可以回到原來的解決方案,但基本上可以扭轉局面 - 只有在用戶訪問文章時才添加一行。所以沒有行=新的,行存在=看到。這將需要更少的行,但它們將根據需要添加。您也可以考慮通過在過去一週內僅通知通知文章來保存數據,因此可以刪除超過1周的所有行。 –
如果您決定採用混合路由來減少複雜性所使用的數據,請查看TCP如何使用滑動窗口跟蹤哪些數據包已被查看以及哪些數據包正在處理。如果你忽略重發部分,它基本上是同樣的問題。 –