我正在实现一个Twitter应用程序，该应用程序需要缓存来自Twitter的用户的详细信息。将数据序列化到一个名为data的列中是否明智？或者，在我的User模型中，我应该为API请求返回的每个字段创建一列吗？
正在读取有关（ActiveRecord:：Base）序列化的信息。
如果我采用后一种方法，我的用户模型中会有很多字段，如果Twitter API决定在未来添加或删除字段，那么我们将不得不分别更新数据库中的列。
然而，我可以想到这种方法的一个优点是，如果每个列都存储在数据库中。我可以说，根据位置搜索所有推特用户。我还可以为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，还是将每个字段保存到其各自的列中，或者两者混合（如上所述）？
您的想法将受到赞赏。
因此，暂时假设您有一个包含以下三列的表：
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纯粹主义者的指责的地方。。。