查询参数因其显而易见的原因而非常有用。但是，当您向不太懂技术的用户提供数据探索器查询时，他们有时会对名称感到困惑（即使它只是一个带有下划线的变量名）。
您能否为查询参数设置别名，以便在查询下方显示一个更友好的名称？
你好 @jordan-violet 
我认为可以这样做——这是你的意思吗？
SELECT column_name AS alias_name
FROM table_name;
...
或者像
SELECT column_name(s)
FROM table_name AS alias_name
....
哦，抱歉，我误解了你的问题！嗯 
1 个赞
是的，我现在有了，但当您试图让销售、市场营销等非技术人员更容易理解这些报告时，它的打磨程度还不够。
事实上，如果能更进一步，还能提供定义工具提示/信息图标描述的选项，那就更好了。
1 个赞
DE 非常原始……构建一个不同的 UI（无论是网页、电子表格还是应用程序）可能是一个好主意。
Grafana 是一个很好的例子！
Grafana 有一个关于他们从 Data Explorer 实时提取的社区报告的实时演示。
4 个赞
是的，我们在业务中使用 Tableau，并且导出所有 Discourse 数据以便在那里使用。
但我确实喜欢让用户（包括内部用户）使用该平台。我总是尽量提倡使用更少的工具，避免工具泛滥。
4 个赞
就我而言，我真的很喜欢这个主意。我认为添加一个“友好的标签/占位符”将是一个很好的补充。但我不知道该如何实现。
2 个赞
有这么多选择！
一个更简单的解决方案是检查当前使用的可选标签变量，例如：
-- [params]
-- text :user_group
-- label: "您想在此查询中查找的客户的Salesforce帐户名称。"
-- text :topic_id
诚然，我已经五年多没有全职从事开发工作了，现在也是如此，所以我不能假装知道当前实现的细节或下一个建议的可能复杂性……但如果你们在 SQL 查询的开头实现了 Front Matter，那将是太棒了。Front Matter 可以是 yaml、toml，甚至是 json，而且肯定比当前的实现更美观。在我看来，它在视觉上看起来更容易添加选项。具有理论 Front Matter 实现的查询可能看起来像这样：
---
user_id:
description: "您想在此查询中查找的客户的Salesforce帐户名称。"
tooltip: "从用户的Salesforce帐户获取此信息，通常与其电子邮件域相关联。它应该完全匹配。"
topic_id:
description: "这是您想研究的主题的ID。"
event_attendance_type:
default: 0
---
SELECT ue.user_id, u.name, u.title, ue.email
FROM discourse_post_event_invitees ei
JOIN posts p ON p.id = ei.post_id
JOIN user_emails as ue ON ue.user_id = ei.user_id
JOIN users as u on ei.user_id = u.id
WHERE p.topic_id = :topic_id
AND ei.status = 0
3 个赞