在 Rails 中导出和/或显示多条记录答案

【问题标题】：Exporting and/or displaying multiple records in Rails在 Rails 中导出和/或显示多条记录
【发布时间】：2013-04-07 03:40:03
【问题描述】：

在过去的 1.5 年里，我一直在 Rails 中工作（我的意思是认真工作）。来自 .Net 背景和数据库/OLAP 开发，我喜欢 Rails 的很多地方，但很少有对我来说没有意义的地方。我只需要澄清一个这样的问题。

我一直在研究一家教育机构的录取流程，这只是更大的申请中的一小部分。现在，对于管理员，我们需要显示所有申请/注册学生的列表（范围可能从 1000 到 10,000），并提供一种将它们导出为 excel 文件的方法。目前，我们只专注于以 CSV 格式导出。

我的问题是：

Rails 是不是要同时显示这么多记录？
will_paginate 是在 Rails 中对记录进行分页的唯一方法吗？据我了解，它仍然从数据库中获取所有记录，然后有选择地显示相关记录。回到 .Net/PHP/JSP，我们曾经创建存储过程并从那里有选择地返回相关记录。既然使用存储过程是 Rails 中的一个已知问题，我们还有哪些其他选择？
导出此数据时同样的问题。我对流程进行了基准测试，即在服务器接收请求、执行查询和响应返回。 ActiveRecord 的创建非常耗时。那是为什么？只有大约 1000 条记录，并且页面显示用户的连接超时。我的意思是，如果在处理 1000 条记录时连接超时，那么为什么要使用 Rails，或者这意味着 Rails 不适用于此类应用程序。我以前处理过 TB 的数据，从来没有遇到过这个问题。
我从不了解 ORM 技术的核心。假设我们有一个表users，并且与多个其他表相关联，但是为了显示记录，我们只需要来自表users 及其关联表admissions 的数据，然后它实际上是否为其所有关联的表创建对象表。我知道，只有我们使用关联才会获取数据，但它会预先创建所有对象吗？

我希望，这些问题不是独立的，并且符合 SF 的指导方针。

谢谢。

编辑：有什么帮助吗？我重新检查并再次进行基准测试，对于 1000 条记录，我们正在加入 4-5 个不同的表（1000 个用户、2-3 个一对一关联和 2-3 个一对多关联），它是创建超过 15000 个对象。这是为了急切加载。至于延迟加载，它将是 1000 个用户查询加上一些 20+ 查询）。对于此类问题和应用，还有哪些其他可能的选择？我知道，我有点想再次提出这个问题！

【问题讨论】：

有什么帮助吗？我重新检查并再次进行基准测试，对于 1000 条记录，我们正在加入 4-5 个不同的表（1000 个用户、2-3 个一对一关联和 2-3 个一对多关联），它是创建超过 10000 个对象。这是为了急切加载。至于延迟加载，它将是 1000 个用户查询加上大约。 10 个额外的查询）。对于此类问题和应用，还有哪些其他可能的选择？我知道，我有点想再次提出这个问题！

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

【解决方案1】：

Rails 可以处理具有 TB 数据量的数据库。

will_paginate 是在 Rails 中对记录进行分页的唯一方法吗？

还有很多其他的宝石，比如“kaminari”。

它从数据库中获取所有记录..

没有。它不是那样工作的。比如下面的查询，Users.all.page(1).per(10)

User.all 不会触发数据库查询，它会返回一个代理对象。然后在代理（ActiveRecord::Relation）上调用 page(1) 和 per(10)。当您尝试从代理对象访问数据时，它将执行数据库查询。活动记录将累积您传递的所有条件和参数，并在需要时执行 sql 查询。

进入rails控制台输入u= User.all; "f";（第二条语句：“f”，是为了防止rails控制台调用代理上的to_s来显示结果。）

它不会触发任何查询。现在试试u[0]，它会触发一个查询。

ActiveRecord 的创建非常耗时

1000 条记录应该不会花费太多时间。

检查从数据库触发的 sql 查询数。寻找迹象 n+1 问题并通过预先加载来修复它们。
检查是否有任何 CPU 或内存密集型操作的记录序列化为 csv 格式。
使用分析器并跟踪占用大部分时间的函数。

【讨论】：

我们一直在使用User.find(:all, ..., :page => something, :per_page => something。我知道这与 ActiveRelations 不同，但它会对应用程序产生很大影响吗？我现在肯定会尝试两者来检查差异。
至于记录的数量，我认为使用 SQL 视图比获取记录然后调用关联更好，这肯定会触发更多的 SQL 查询。我已经检查并删除了 N+1 问题（通过创建视图）。正如我已经提到的，我尝试对导出请求进行基准测试（我不记得 gem 的名称，我会在系统上检查后告诉你），返回创建 ActiveRecord 对象所需的时间。我阅读的另一种方式是使用ActiveRecord::Base 的execute 命令并使用这个原始结果来获取ActiveRecord::Result。
您不必创建视图来摆脱 n+1 个问题。结帐railscasts.com/episodes/22-eager-loading。
是的，我知道这一点，但查看这里帮助我了解了我的旋转列集，并且直接使用它们而不是编写许多 if-else 条件（或 switch 案例）。另外，即使在急切加载中，模型会为所有关联创建对象还是仅为加载的数据创建对象？我只指对象（有或没有数据）。
1 点我错过了添加。即使使用预加载，对于每个user 对象，我们也需要从 5-6 个其他表中获取相关数据，这些数据（或要创建的对象数量很大）。对于 1000 条记录，基准显示创建了 20000 多个对象（某些对象可能有超过 1 个关联记录，如一对多关系）。这对我们来说也可能是错误的，但在预加载期间，我们确保只获取需要的列。