重构我的数据库架构

Question

我正在重构我当前的模式，它对我来说太抽象了。

我用自制的监控软件监视我的服务器。这个软件向Rails web服务器发送HTTP请求，其中包含大约10个不同字段的信息，这样我就可以快速了解所有信息。

我目前的执行情况：

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

我将服务器视为用户，将状态更新视为Tweets。我删除了一个比第十个status_update更老的server_id，只是为了不让它增长到无穷大。

虽然我开始遇到一些复杂的事情。我需要在索引页面上显示来自最近status_update的信息，我需要根据status_update信息对服务器进行排序，我需要存储来自某些status_updates的信息，这些信息可能比10 status_updates老的要早得多。我似乎还需要将来自status_updates的信息存储在服务器和status_update中，这将导致在插入时多次命中DB。因此，我期待重构。

我的要求:我只需要显示最新更新的信息。如果系统脱机，拥有下一个9 status_updates有助于调试。我需要能够根据最近的status_update中的一些信息进行排序。我需要数据库保持小(Heroku免费)。理想的性能，IE不超过一次命中数据库，除非必要。不复杂的DB结构，这样我就可以传递它了。

编辑:附加信息 =>，我希望最终监控大约1500-200台服务器(对于业余爱好开发来说，这是很多事情，但我很便宜)。每个监控服务大约每五分钟发布一次，除非出了什么问题。所以，最坏的情况是，我每隔四个小时就能达到最大容量。

我在想，如果能追踪上一次X事件发生的时间，以及结果是什么，那就太好了。因此，跟踪这些信息必须移动到server模型本身，因为我正在删除旧记录，并在大约一个小时后丢失信息。尽管回想起来，我可以使用监视服务将该信息保存在内存中，并且每五分钟发送一次，或者每次更改时只发送一次。我也可以只在信息发生变化时编辑该信息，以便对每个请求处理较少的信息。嗯！

Answer 1

效率

所有的ORM，包括ActiveRecord，都是围绕某些权衡而设计和构建的。对于ORMs来说，使用几个简单的SELECT语句来执行SQL开发人员对单个SELECT语句的操作是很常见的。你可能不会因为你的问题而压倒Heroku。

这个问题没有合理的结构性解决办法。

尺寸

您的"status_update“表应该能够容纳大量行。Heroku的业余发展计划允许10,000行。对于一个免费的计划，你真的希望监视多少台服务器？如果我是您，我将删除旧行每天最多一次，或当我得到一个权限错误。(在Heroku，某些权限错误意味着您超过了行限制。)

我似乎还需要将来自status_updates的信息存储在服务器和status_update中，这将导致在插入时多次命中DB。

这真的没什么意义。Tweet不需要更新用户帐户；状态更新不需要更新服务器。这可能意味着重构是合适的，但我希望看到您的模型或CREATE语句是确定的。(您可以将这些内容粘贴到您的问题中，并在这里留下评论。)

替代品

我会认真考虑在本地机器上运行这个Rails应用程序，将数据写入本地机器上的数据库，特别是如果您打算针对200个web服务器。这将消除所有Heroku行的限制，如果这只是一种爱好的话，您不需要每天24小时运行它。如果你是专业的，你从它得到的收入应该很容易支付一个爱好的费用--关于Heroku的基本计划。(现时每月9元)但即使如此，我还是会认真考虑在本地举办这个节目。