【问题标题】:Rails as web service: store data as json hash vs activerecord entitiesRails 作为 Web 服务:将数据存储为 json 哈希与 activerecord 实体
【发布时间】:2025-11-25 06:45:01
【问题描述】:

我正在创建一个带有 Rails 服务器的 iOS 应用,用于跨设备存储和同步用户信息。

举个例子,假设我的用户有一封用于唯一标识自己的电子邮件和一个地点列表:

{
    email: ...,
    places: [
        {
            id: ...,
            name: ...,
            latitude: ...,
            longitude: ...,
            category: ...
        },
        ...
    ]
}

在我的 iOS 应用中,我有 UserPlace 实体/类。

我是否应该在 Rails 中也有一个 Place activerecord 实体以及迁移中的参数(名称、纬度、经度、类别),或者我应该只有一个 Place 实体与 iddata、@ 987654328@ 是一个包含“名称”、“纬度”、“经度”和“类别”键的哈希?

我看到第二种方法的一个优点是,如果我在 iOS 应用程序中更新我的模型,我不必在 Rails 服务器中也更新它,因为它只为每个地方存储一个哈希值。

我该怎么办?

【问题讨论】:

    标签: ios ruby-on-rails activerecord client-server


    【解决方案1】:

    这在很大程度上取决于:

    • 关于您需要多久更新一次哈希中的信息
    • 是只更新一项还是更新哈希中的所有数据
    • 您要使用什么数据库或其他存储
    • 此数据是否需要通过属性或仅通过 id 进行搜索

    我认为您将能够看到将指导您做出决定的因素。

    关于使用存储为文档的 JSON 的明显灵活性以及避免在需求变化时更新架构的明显灵活性需要注意的一点是,您必须非常小心,您的服务器和应用程序可以处理数据中的意外变化JSON结构和数据完整性。使用关系数据库,您可以获得一些在允许使用任意 JSON 时丢失的结构和控制感。这很好,但您必须注意在整个架构中更仔细地处理意外丢失或额外的数据。

    还有很多话要说,但这是我对您的要求的看法。

    【讨论】:

    • 假设我现在不关心性能,并且我的服务器将主要用于同步,所以除了检查时间戳以查看哪些数据更新外,没有太多逻辑。在这种情况下,您会使用哪种方法?
    • 如果您假设添加逻辑的要求不会改变,通过简单的文档存储来保存并随后加载最新版本,那么您可能正在寻找一个经典的 noSQL 要求。人们喜欢 MongoDB。我是 ElasticSearch 的忠实粉丝,因为它提供灵活的 JSON 搜索以满足未来的需求。 Postgres 也有一些 JSON 功能,如果您最终想要索引某些 JSON 属性,并且也可以使用标准的关系内容。我们都有自己喜欢的工具。我可能会根据可扩展性要求进行选择。