缓存 API 数据，我应该将数据序列化为单列吗？还是其他方法？答案

【问题标题】：Caching API data, should I serialize the data into a single column? Or other approach?缓存 API 数据，我应该将数据序列化为单列吗？还是其他方法？
【发布时间】：2011-06-11 02:06:00
【问题描述】：

我正在实现一个 Twitter 应用程序，该应用程序需要缓存来自 Twitter 的用户的详细信息。将数据序列化到名为data 的列中是否明智？或者，在我的用户模型中，我应该为API request 返回的每个字段创建一个列吗？

阅读(ActiveRecord::Base) serialize。

如果我采用后一种方法，我最终会在我的用户模型中得到很多字段，如果 Twitter API 决定将来添加或删除字段，那么我们将不得不更新我们的数据库中的列分别。

但是，我可以想到这种方法的一个优点是，如果每一列都存储在 db.xml 中。我可以说，根据位置搜索所有 Twitter 用户。我还可以索引location 列以获得更快的查询。这与序列化方法相比如何？

有人会建议：“不要搜索序列化数据，就不要这样做”。

所以我想，我可以有两列：data（用于序列化数据）和location，不是吗？

但是让我们再添加一些曲折：

应用程序需要按注册日期对用户进行排序。不是我们的应用，而是 Twitter。
该应用应该能够通过 Twitter 屏幕名称或 Twitter ID 搜索用户。
该应用应该能够按关注者、朋友和状态计数对用户进行分类。

这是否意味着，我的数据库中需要 8 列：data、location、twitter_created_at、twitter_screen_name、twitter_id、followers_count、friends_count 和 statuses_count？在这一点上，是采用混合列类型的方法还是将每个字段单独放在自己的列中会更好吗？

您是将 API 返回的数据保存到单个列中：data，还是将每个字段保存在其各自的列中，或者两者兼而有之（如上所述）？

您的想法将不胜感激。

【问题讨论】：

考虑为此创建一个关联表，其中包含用户 ID、名称和值列。然后，您可以建立一对多关系来存储这些字段。将来，如果有效的字段集发生更改，您只需在此表中添加或删除与用户关联的行。
Jaydel，我不确定我明白你的意思。您认为您可以为此提供一个示例来更好地说明您的建议吗？
是的，我会把它放在一个答案中，以便我得到格式......
太好了，期待:-)

标签： ruby-on-rails ruby-on-rails-3 twitter

【解决方案1】：

假设您有一个包含以下三列的表格：

user_id, api_field_name, api_field_value

在此表中，您可以为要保留的每个 api 字段添加一行。例如：

user_d     api_field_name        api_field_value
1          "meaning_of_life"     42
1          "swallow_type"        "africa"

这意味着用户编号 1 有这两个与 api 绑定的自定义参数...如果稍后 api 更改并且“swallow_type”被删除，您可以摆脱该行。可以动态添加新的 api 字段。

这是一种处理可以并且确实会定期更改的自定义参数的简单方法。它使您不必在每次 api 更改时重新构建表。

这就是我躲避来自 DB 纯粹主义者的抨击的地方...

【讨论】：

有趣的解决方案。假设 Twitter API 返回 20 个字段。这意味着每个用户都与此表中的 20 个字段相关联？如果我有 500k 用户注册，那么仅此表中的 500*20 5,000,000,000 条记录仅用于保存 API 数据？耶！另一个问题是，当我需要更新、删除或添加新字段名称时会发生什么。我必须通过 5,000,000,000 行才能更新字段？这会有任何性能缺陷吗？
它可以。也许一些激进的索引会降低这一点，但是是的，需要管理很多行。鉴于此，序列化数据可能会更好（JSON 似乎是一个有趣的想法），但我一直反对这种方法，因为如果您需要通过此序列化中的一个或多个事物查找用户，您'可能会发现更多的痛苦。但是，如果您所做的只是加载它们、解析它们然后应用它们，那么序列化并不是一个可怕的想法。我总是尽量避免这种做法，但我也坚信在需要时会“打破”规则。