概括：我提出了一個可視化的 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。我相信透過JMP Workflows 17，我們也能擁有這樣的觀點。
嗨@Ryan_Gilmore ，聽起來不錯 - 你能重新打開這個願望嗎？
作為記錄，我仍然認為這是一個相關的建議。視覺化流程方法是一種處理 ETL 流程的靈活方法，並且不會被工作流程所取代，工作流程實際上將每個步驟作為按順序呼叫的函數。
@Sarah-Sylvestre有機會重新提出這個請求嗎？
這個願望的目標是直觀地創造工作流程。
@jthi的相關願望
JMP 中不同報表與資料表之間的參考視覺化
具有可視化現有關係的想法。
