我正在重构我当前的架构，这对我来说太抽象了。
我使用自制的监控软件监控我的服务器。该软件将HTTP请求发送到Rails Web服务器，该服务器包含大约十个不同字段的信息，因此我可以快速浏览所有内容。
我目前的实施：
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 old。我似乎还要开始需要在服务器和status_update中存储来自status_updates的信息，这会导致在插入时多次击中DB。因此，我期待重构。
我的要求： 我只需要显示最新更新的信息。 如果系统脱机，拥有接下来的9个status_updates有助于调试。 我需要能够根据最近的status_update中的一些信息进行排序。 我需要数据库保持小（Heroku免费）。 理想的性能，除非必要，否则IE不会多次访问数据库。 非复杂的DB结构，所以我可以传递它。
修改：其他信息 =＆gt;我期待最终监控大约150-200台服务器（很多爱好开发，但我很便宜）。每个监控服务每五分钟左右发布一次，除非出现问题。因此，最糟糕的情况是我每四个小时达到最大容量。
我认为跟踪X事件最后一次发生的时间以及结果是什么会很好。因此，跟踪该信息将不得不移动到server模型本身，因为我正在消除旧记录并且在一小时左右之后将丢失该信息。虽然回想起来，我可以使用监控服务将该信息保存在内存中，并且每隔五分钟发送一次，或者每次更改时发送一次。我也可以只在它改变时编辑该信息，以便处理每个请求的更少信息。哼！
答案 0 :(得分：1)
<强>效率
所有ORM（包括ActiveRecord）都是围绕某些权衡而设计和构建的。 ORM使用几个简单的SELECT语句来执行SQL开发人员对单个SELECT语句的操作是很常见的。你可能不会用你的疑问压倒Heroku。
这个问题没有合理的结构性解决方案。
<强>尺寸
你的＆＃34; status_update＆＃34;表应该能够容纳大量的行。 Heroku的业余爱好计划允许10,000行。您真的希望在免费计划中监控多少台服务器？如果我是你，我会每天不超过一次删除旧行，或者当我收到权限错误时。 （在Heroku上，某些权限错误意味着您已超过行限制。）
我似乎也开始需要存储信息 来自server和status_update中的status_updates 导致在插入物上多次击中DB。
这真的没什么意义。推文不需要更新用户帐户;状态更新不需要有关服务器的更新。 此可能会建议重构是有序的，但我想要确定您的模型或CREATE TABLE语句。 （您可以将这些内容粘贴到您的问题中，并在此处发表评论。）
<强>替代
我认真考虑在本地计算机上运行此Rails应用程序，将数据写入本地计算机上的数据库，特别是如果您打算定位200个Web服务器。这将消除所有Heroku行限制，如果这只是一个爱好，你不需要一天24小时运行它。如果你专业地做这件事，你的收入应该很容易弥补Heroku的业余爱好基本计划的成本。 （目前每月9.00美元。）但即便如此，我也很想在本地托管这个。