在Rails中，存储常量数据并在其他地方引用这些数据是一个常见的需求。为了解决这个问题，可以按照以下步骤进行操作。

首先，创建一个名为config/app_constants.yml的文件，用于存储常量数据。在该文件中，按照环境（production、test、development）划分，定义不同的常量数据。例如：

production:

接下来，在lib/app_constant.rb文件中创建一个名为AppConstant的模块，并定义相关的方法。具体代码如下：

module AppConstant
  extend self
  CONFIG_FILE = File.expand_path('../config/app_constants.yml', __FILE__)
  @_constants = YAML.load(File.read(CONFIG_FILE))
  @ = @_constants[Rails.env]
  def get_time_list
    @['time_list'].split(',')
  end
end

最后，在任何需要引用这些常量数据的地方，可以调用AppConstant.get_time_list方法来获取时间列表的数组。例如：

AppConstant.get_time_list #将返回一个数组

通过这种方式，你只需要在app_constants.yml文件中修改一次，就可以在应用程序中的任何地方反映出这些修改。这样做可以使代码更加清晰，方便维护和修改。

在Rails中，我们经常会遇到需要存储常量数据并在应用程序中引用的情况。那么问题来了，我们应该将常量数据存储在哪里，并如何在Rails中引用它呢？

有人倾向于将这种类型的数据放在与之最相关的模型中。例如，如果上述示例中的时间是备份运行的时间，可以将它们放在与备份相关的Backup模型中，与其他与备份相关的行为一起：

# app/models/backup.rb
class Backup < ActiveRecord::Base
  AVAILABLE_RUN_TIMES = %w{7:00am 7:30am ...}
  def run_at=(date)
    BackupSchedule.create(self, date)
  end
end
# app/views/backups/_form.html.erb
<%= select_tag(:run_at, options_for_select(Backup::AVAILABLE_RUN_TIMES)) %>

我曾经也使用过“大桶常量”的方法，但只有在没有更相关的地方存储常量时才会使用它。

这种方法的好处是常量数据与模型紧密相关，易于维护和管理。同时，通过将常量数据放在模型中，我们可以在模型的方法中直接引用它们，使代码更加清晰和易于理解。

通过上述示例，我们可以看到将常量数据存储在模型中的步骤：

1. 在模型中定义常量：在Backup模型中，我们定义了一个名为AVAILABLE_RUN_TIMES的常量，它包含备份运行的时间。

2. 在视图中引用常量：在备份的表单视图中，我们使用options_for_select方法将Backup::AVAILABLE_RUN_TIMES作为下拉选择框的选项。

总结起来，将常量数据存储在与之最相关的模型中，并在需要引用的地方使用模型名::常量名的方式来访问它们，是一种在Rails中处理常量数据的常见且有效的方法。这种方法能够帮助我们更好地组织和管理代码，同时提高代码的可读性和可维护性。

问题的出现的原因是在Rails中，常量数据应该存储在哪里以及如何引用它。

解决方法是创建一个名为"Constants"的模块，并将其放置在lib目录下。在这个模块中，定义常量数据。然后，在需要引用这些常量数据的地方，使用"Constants::常量名"的语法进行引用。

在配置文件中，确保将"libs"目录添加到自动加载路径中，以便Rails能够找到"Constants"模块。

另一种解决方法是在"/config/initializers"目录下创建一个名为"global_constants.rb"的文件，并在其中定义常量数据。然后，在需要引用这些常量数据的地方，使用对应的语法进行引用。

某些情况下了使用yaml文件存储常量数据的方法，但是被认为在这种情况下过于复杂了。

还有人建议将常量定义在使用它的类中，如果常量不需要在多个地方共享的话。但是，问题描述中提到了这些常量会在多个地方被引用。

最后，某些情况下了在初始化器中尽量避免添加过多的信息，只添加对Rails启动所需的内容。将自动加载（autoload）发挥作用，避免在启动时加载过多的数据，可以提高启动速度。