概括：我提出了一個可視化的 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 文件（或其他文件）或可以從加載項或腳本窗口運行的已保存腳本。
我附上了一張畫得很糟糕的圖片，說明我在想什麼。 如果這激起了開發者的興趣，如果您想聯繫討論這個問題，請隨時通過私信與我聯繫！
注意：編輯格式化
