# 在 CSV 用户列表报告中获取（访问天数）
**URL:** https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079
**Category:** Feature
**Created:** [2020年一月29日 16:11 UTC](https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079 "2020-01-29T16:11:36Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@YaserAlnajjar](https://meta.discourse.org/u/YaserAlnajjar)
#### Post date: [2020年一月29日 16:11 UTC](https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079/1 "2020-01-29T16:11:36Z")
您好，
我们在以下链接中可以看到“访问天数”这一列：
[https://LINK/admin/users/2/USERNAME](https://LINK/admin/users/2/USERNAME)
如果能在从以下路径生成的 CSV 用户列表文件中包含该列，那就太好了：
**管理面板 =\> 用户标签页 =\> “导出”按钮**
---
### Author:  [@Mittineague](https://meta.discourse.org/u/Mittineague)
#### Post date: [2020年一月29日 18:42 UTC](https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079/2 "2020-01-29T18:42:44Z")
这恐怕不是您想听到的，但……
用户导出文件包含来自用户表（User table）的字段。
“`days_visited`”字段来自用户统计表（User\_Stats table）。
将完全相同的数据重复存储（例如，如果该字段同时存在于两个表中）属于“反规范化”（anti-normalization）。据我所知，您看到的结果是一个 JOIN 查询的输出，该查询不仅使用了用户表，还关联了与用户相关的其他表。
不过，使用数据探索器（[Data Explorer](https://meta.discourse.org/t/32566?silent=true)）插件，您完全可以轻松运行此类 JOIN 查询，生成包含该字段的导出文件。
---
### Author:  [@YaserAlnajjar](https://meta.discourse.org/u/YaserAlnajjar)
#### Post date: [2020年一月29日 20:48 UTC](https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079/3 "2020-01-29T20:48:44Z")
不够精确，CSV 文件包含 likes\_given 和 likes\_received 列，这些列也存在于同一个表 user\_stats 中：
```plaintext
--
-- Name: user_stats; Type: TABLE; Schema: public; Owner: discourse
--
CREATE TABLE public.user_stats (
user_id integer NOT NULL,
topics_entered integer DEFAULT 0 NOT NULL,
time_read integer DEFAULT 0 NOT NULL,
days_visited integer DEFAULT 0 NOT NULL,
posts_read_count integer DEFAULT 0 NOT NULL,
likes_given integer DEFAULT 0 NOT NULL,
likes_received integer DEFAULT 0 NOT NULL,
topic_reply_count integer DEFAULT 0 NOT NULL,
new_since timestamp without time zone NOT NULL,
read_faq timestamp without time zone,
first_post_created_at timestamp without time zone,
post_count integer DEFAULT 0 NOT NULL,
topic_count integer DEFAULT 0 NOT NULL,
bounce_score double precision DEFAULT 0 NOT NULL,
reset_bounce_score_after timestamp without time zone
);
```
[来自 schema.sql](https://github.com/prisma/database-schema-examples/blob/master/postgres/discourse/schema.sql#L4984)
---
### Author:  [@Mittineague](https://meta.discourse.org/u/Mittineague)
#### Post date: [2020年一月29日 21:11 UTC](https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079/4 "2020-01-29T21:11:29Z")
谢谢，你说得对。看来这里涉及的内容比我以前记得要更多。
>
---
### Author:  [@YaserAlnajjar](https://meta.discourse.org/u/YaserAlnajjar)
#### Post date: [2020年一月30日 13:14 UTC](https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079/5 "2020-01-30T13:14:33Z")
感谢指出相关文件 😄
既然 `topics_entered` 和 `get_base_user_array` 函数中的其他列一样确实存在……这看起来是不是一个 bug？
---
### Author:  [@Mittineague](https://meta.discourse.org/u/Mittineague)
#### Post date: [2020年一月30日 15:08 UTC](https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079/6 "2020-01-30T15:08:21Z")
有些我感兴趣的字段在导出中并不存在（大约是一两年前）。我原以为这是有意为之而非漏洞，但从未进一步核实。导出功能后来仅限管理员使用，由于无法再获取真实数据进行操作，难度增加，兴趣也随之减退，加之现实生活的一些重压，最终让我放弃了这条路径。
若不深入查看，我大胆猜测：如果核心代码未作改动，通过插件可以轻松从数据表中获取这些值并添加到 CSV 导出中。不过，我认为“数据探索器”插件是进行自定义导出的一个良好候选方案。
目前，我的兴趣大多已从对仅限管理员的核心文件进行“黑客式”修改，转向了编写定制化的用户脚本。
或许在达成足够共识的情况下，当前的导出功能可以作出调整？
---
### Author:  [@YaserAlnajjar](https://meta.discourse.org/u/YaserAlnajjar)
#### Post date: [2020年一月30日 17:30 UTC](https://meta.discourse.org/t/getting-days-visited-in-csv-user-list-report/140079/7 "2020-01-30T17:30:18Z")
我已经编写了所需的查询：
```plaintext
SELECT
u.username_lower AS "username",
stats.days_visited
FROM users u
LEFT JOIN user_stats stats ON stats.user_id = u.id
ORDER BY u.id
```
不过，这些数据在用户列表报告中确实很有用，可以提供一些洞察。
谢谢 @Mittineague 🌹