概括：我提出了一个可视化的 Table Builder 界面，它允许数据库选择、数据库内操作（例如连接和过滤）、内存中操作（例如“Table>Concatenate”和“Rows> Select Where...”）以及一些 JSL 操作（例如 Add）要在视觉流中链接的属性。 我相信这种方法会提供一种非常直观的方式适用于几乎没有接受过数据科学培训的人员，可以自动进行数据准备和清理，轻松将实时数据源捕获到 JMP 中，以生成洞察力和进行分析。
细节：我发现自己经常使用 JMP 查询生成器从我们的内部 Postgres 数据库创建数据查询，它作为基本的数据库查询工具运行良好。 也就是说，我仍然发现自己返回到 Python、KNIME 或原始 SQL 来处理更复杂的工作流，例如通过连接两个子查询来生成表，它们本身是对基表进行连接和转换的结果。 不过，最终，我仍然需要进行一个简单的 JMP 查询，以从数据库中获取 JMP 中的数据。 此外，当前的查询构建器相当慢，并且对于那些没有扎实的数据库操作基础的人来说不是很直观。
KNIME 和 Alteryx 在这里采用的方法对我来说感觉非常好：一种适合于强大的数据库操作心智模型的可视化流程。 每一步都会生成一个新的虚拟表（实际上是一个抽象的 SQL 操作），然后可以将其拼凑成更大的查询。
在 KNIME 中配置单个步骤也比在查询生成器中快得多，我假设是因为谓词步骤保留在内存中，只有修改后的操作需要在上一步的内存中表示上执行。 QB 而不是运行大量 SQL 查询（关闭自动预览有很大帮助，但您失去了预览功能）。 基本上，每次您选择一个列或重命名一个自动预览的列时，都是一次数据库查询和流程中断。
我认为改进 Query Builder 将大大有助于科学家和工程师实现数据操作和数据库使用的民主化。 这是我的建议：
- 将表选择与连接操作和过滤/排序分开
- 这可以利用现有的查询构建器，就像选择了单个表一样。 选择和重命名列的 JMP QB 方法非常好！
- 尽可能使用内存中的表示例（包括所有列和 ~100-500 行）进行预览操作，以尽可能避免 SQL 查询，因为 IO 是目前大多数操作中最慢的部分。
- 我在其中包括列选择、重命名、分组依据、聚合函数等。
- 一个可能的问题是表格过宽（想到生物信息学），因此内存模式可能也需要列限制，但我非常有信心它将涵盖绝大多数用途。
- 构建用于加入、过滤、排序/按操作排序的可视化流表示。
- 如果可能，每个操作都将使用内存中的表示形式来预览输出。
- 源表样本的内存表示也将消除为连接操作查询列名的需要，这在 JMP 中是非常慢的步骤。
- 理想情况下，允许将 JMP 表操作（拆分、堆叠、连接，甚至可能添加带有公式的列、行选择、行隐藏和排除等）作为从数据库查询后的可视化步骤链接到流程。
- 我发现我的很多同事最终将各种数据清理和准备步骤串在一起作为菜单操作，然后我需要帮助将它们转换为查询后脚本。
- 将脚本附加到最终数据表也可以是一个可视化步骤，这将有助于为 N 个附加脚本提供一系列 N 个步骤的便利流程。
至少从 UI 的角度来看，这些部分中的大部分或全部都可以利用 JMP 中的现有 UI：JMP 表连接步骤的配置面板实际上可以使用与 JMP 中的表 > 连接选项相同的格式。
我的理想状态是，没有受过大量 SQL 或数据库培训的同事可以轻松地尝试表选择、连接、过滤和数据准备，最终得到一个完全自动化的工作流，从而生成他们进行可视化和分析所需的表. 我认为视觉流方法是促进这一点的好方法！ 这将是一个真正的 Table Builder，结合了数据库查询、数据库中操作和内存中表、行、列和脚本操作的特性，以构建全自动数据准备工作流。
最终输出有点像查询生成器：将打开表生成器流的 .jmpflow 文件（或其他文件）或可以从加载项或脚本窗口运行的已保存脚本。
我附上了一张我在想什么的画得不好的照片。 如果这激起了开发人员的兴趣，如果您想连接讨论这个问题，请随时通过私人消息与我联系！
注意：编辑格式
+1。我相信，借助 17 版 JMP Workflows，我们也可以获得这种视图。
你好@Ryan_Gilmore ，听起来很棒 - 你能重新打开这个愿望吗？
顺便说一句，我仍然认为这是一个相关的建议。可视化流程方法是处理 ETL 流程的一种灵活方法，不会被工作流所取代，工作流实际上是按顺序调用每个步骤的函数。
@Sarah-Sylvestre有机会重新打开这个请求吗？
这个愿望的目标是直观地创建一个工作流程。
@jthi的相关愿望
JMP 中不同报告和数据表之间的参考可视化
其想法是将现有的关系形象化。
