重構我的數據庫模式

Question

我正在重構我當前的模式，這對我來說太抽象了。

我用自制的監控軟件監控我的服務器。該軟件將HTTP請求發送到Rails Web服務器，並提供大約10個不同字段的信息，以便我可以快速瀏覽所有內容。

我目前的執行情況：

server [id, name, created_date, edited_date, ..., etc ] 
status_update [id, server_id, field1, field2, field3, created_date, edited_date, ..., etc] 

我把服務器爲用戶和狀態更新爲鳴叫。我刪除了比第十個更早的server_id上的任何status_update，以防止增長到無窮大。

雖然我開始遇到一些併發症。我需要顯示索引頁上最新status_update的信息，我需要根據status_update信息對服務器進行排序，我需要存儲某些status_updates中的信息，該信息可能會比10個status_updates舊。我似乎也開始需要將status_updates中的信息存儲在服務器和status_update中，這會在插入時多次觸發數據庫。因此，我期待重構。

我的需求： 我只需要顯示來自最新更新的信息。 接下來的9個status_updates有助於調試系統是否脫機。 我需要能夠根據最近status_update的一些信息進行排序。 我需要數據庫保持小型（Heroku免費）。 理想的性能，除非必要，否則IE不會超過一次。 非複雜的數據庫結構，所以我可以傳遞它。

編輯：額外信息 =>我期待最終監測大約150-200個服務器（很多是業餘愛好，但我很便宜）。除非出現問題，每個監控服務每五分鐘發佈一次。所以，最壞的情況是我每四個小時達到最大容量。

我在想，跟蹤上一次發生X事件的時間以及結果是什麼會很好。因此，跟蹤這些信息將不得不被移到server模型本身，因爲我正在清除舊記錄，並在一小時左右後丟失信息。雖然回想起來，我可以使用監控服務將這些信息保存在內存中，並且每5分鐘發送一次，或者每次更改時只發送一次。我也可以簡單地修改這些信息，以便處理每個請求的更少信息。哼！

Answer 1

效率

所有的ORM，包括ActiveRecord的，在設計和周圍一定權衡建造。對於ORM來說，使用幾個簡單的SELECT語句來做一個SQL開發人員用一個SELECT語句來做什麼是很平常的。你可能不會用你的疑問來壓倒Heroku。

這個問題沒有合理的結構解決方案。

尺寸

你「status_update」表應該能夠容納的行數量巨大。 Heroku的愛好 - 開發計劃允許10,000行。您有多少臺服務器可以真正期望在免費計劃中進行監控？如果我是你，我會每天從它刪除舊的行，或者我有權限錯誤。 （在Heroku上，某些權限錯誤意味着你超出了行限制。）

它也好像我要開始需要存儲在服務器和status_update都status_updates的，這將導致 上打一個插入的DB多次信息 。

這真的沒什麼意義。推文不需要更新用戶帳戶;狀態更新不需要關於服務器的更新。 這可能暗示重構是爲了順序，但我想看看你的模型或你的CREATE TABLE語句是肯定的。 （你可以粘貼到那些你的問題，並在這裏發表評論。）

替代

我會認真考慮在運行此Rails應用程序在本地機器上，本地機器上的數據寫入到數據庫，特別是如果你打算瞄準200個Web服務器。這將消除所有Heroku行限制，並且如果這僅僅是一種愛好，您並不需要一天24小時運行它。如果你在專業上做這件事，你的收入應該很容易支付Heroku基本計劃的成本。 （目前每月9.00美元）。但即使如此，我也會認真考慮在本地託管這些東西。