ruby-on-rails - Rails 5 Active Record - 是否可以在内存中保存一个表？

Question

如果我们有一个包含相对静态数据的小表，是否可以让 Active Record 在应用程序启动时加载它，而不必为这些数据访问数据库？

请注意，理想情况下，我希望这些数据可以从与其有关系的其他模型中加入。

一个例子可能是带有电话号码前缀的国家/地区列表 - 此列表不太可能更改，如果更改，管理员将更改。其他表可能与此有关系(例如，给定一个引用国家/地区的用户，我们可能想要查找国家/地区电话前缀)。

我看到一个类似的问题here , 但它已经 6 岁了，指的是 Rails 2，而我使用的是 Rails 5，也许从那时起就引入了一些东西。

首选解决方案是:

1. 内置 Rails/ActiveRecord 功能，可在启动时加载一次表，如果随后加载与缓存表有关系的其他记录，则自动链接到缓存对象(即手动缓存 MyModel.all 某处是还不够，因为关系仍然会通过查询数据库加载)。
2. 维护执行上述操作的库。
3. 如果两者都不可用，我想另一种方法是将静态数据集定义为内存中的枚举/哈希或类似的，并将哈希键保存在与该数据有关系的记录上，并定义方法这些模型使用数据库中保存的键使用散列中的对象进行查找。虽然这看起来很手动......

[编辑]潜在解决方案需要考虑的另一件事——手动解决方案 (3) 还需要自定义 Controller 和路由，以便通过 API 访问此类数据。理想情况下，如果需要使用脚手架等标准 rails 机制，无需太多人工干预，就可以通过 RESTful API(只读 - 仅获取)提供此类数据，这在理想情况下会很好。

Answer 1

我认为您可能过快地否定了“简单”/“手动”方法。

将数据写入 ruby​​ 散列/数组并不是一个坏主意。

如果您想使用 CRUD 脚手架，为什么不直接使用标准 Rails 模型/ Controller 生成器呢？在数据库中存储一些静态数据真的有那么糟糕吗？

第三种选择是以某种序列化格式将您的数据存储到一个文件中，然后在您的应用程序加载时读取它并构建 ActiveRecord 对象。让我举个例子:

data.yml

---
- a: "1"
  b: "1"
- a: "2"
  b: "2"

这是一个包含哈希数组的 YAML 文件；你可以构建这样一个文件:

require 'yaml'
File.open("path.yml", "w") do |f|
  data = [
    { "a" => "1", "b" => 1 },
    { "a" => "2", "b" => 2 }
  ]
  f.write(YAML.dump(data))
end

然后要加载数据，您可以在 config/initializers/ 中创建一个文件(此处的所有内容都将由 rails 自动加载):

config/initializers/static_data.rb

require 'yaml'

# define a constant that can be used by the rest of the app
StaticData = YAML.load(File.read("data.yml")).map do |object|
  MyObjectClass.new(object)
end

为了避免为 MyObjectClass 编写数据库迁移(当它实际上没有存储在数据库中时)，您可以使用 attr_accessor 定义您的属性:

class MyObjectClass < ActiveRecord::Base
  # say these are your two columns
  attr_accessor :a, :b
end

只需确保不要在此模型上运行save、delete 或update 之类的东西(除非您对这些方法进行猴子修补)。

如果你想拥有 REST/CRUD 端点，你需要从头开始编写它们，因为现在更改数据的方式不同了。您基本上需要分三步进行任何更新:

1. 将 YAML 中的数据加载到 Ruby 对象列表中
2. 更改 Ruby 对象列表
3. 将所有内容序列化为 YAML 并保存。

所以您可以看到您并没有真正在此处进行增量更新。您可以使用 JSON 而不是 YAML，您也会遇到同样的问题。使用 Ruby 的内置存储系统 PStore，您将能够单独更新对象，但是将 SQL 用于生产 Web 应用程序是一个更好的主意，并且老实说会让事情变得更简单。

除了这些“序列化数据”选项之外，还有键值存储服务器将数据存储在内存中。像 Memcached 和 Redis 这样的东西。

但是回到我之前的观点，除非您有充分的理由不使用 SQL，否则只会让事情变得更加困难。