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