Tools mentioned in this article
Open the browser-based tool while you read and try the workflow immediately.
用最快的方式取得「先給我一份 CREATE TABLE」
開始開發新功能時，腦中通常已經有大致需要哪些資料表的輪廓。把它寫成 CREATE TABLE 語句雖然是單純的作業，卻意外地耗時：每次都要回想欄位型別、重新查詢 MySQL 與 PostgreSQL 的語法差異、或是把外鍵語法寫錯。
DDL 產生器 只要在畫面上組合資料表與欄位，就能同時產生符合 MySQL / PostgreSQL / SQLite 各自格式的 CREATE TABLE 語句，以及 Mermaid 格式的 ER 圖。貼上 JSON 範例還能自動推論欄位結構。所有處理都在瀏覽器內完成，您輸入的資料表設計不會傳送到外部。
本文將從實作角度說明工具內部發生了什麼事——型別如何轉換，以及如何從 JSON 推論欄位。
建立資料表的三種方式
- 由 JSON 自動產生：貼上 API 回應或日誌的 JSON 範例，工具會自動推論欄位名稱、型別、主鍵與 NOT NULL 並新增資料表。
- 手動設計資料表：直接在畫面上編輯資料表名稱、欄位名稱、型別、PK/NOT NULL/UNIQUE/自動遞增與預設值。
- 關聯：只要選擇來源資料表／欄位與目標資料表／欄位，就會加上外鍵約束以及 ER 圖中的關聯線。
產生的 DDL 可以直接交給 Visual SQL Builder 繼續組建查詢，或日後貼到 SQL 轉 ER 圖 重新檢視結構。從設計到查詢的整個流程都能在瀏覽器內完成。
型別在不同資料庫之間如何轉換
工具在內部以不依賴特定資料庫的共通「邏輯型別」來管理資料表：
export type LogicalType =
| 'INTEGER' | 'BIGINT' | 'DECIMAL' | 'VARCHAR' | 'TEXT'
| 'BOOLEAN' | 'DATE' | 'DATETIME' | 'JSON' | 'UUID';只有在產生 DDL 的當下，才會依照所選方言轉換為實際的 SQL 型別。其中最值得注意的是 SQLite 沒有布林型別與 JSON 型別所產生的轉換，以及主鍵自動遞增語法的差異。
| 邏輯型別 | MySQL | PostgreSQL | SQLite |
|---|---|---|---|
BOOLEAN | BOOLEAN | BOOLEAN | INTEGER |
JSON | JSON | JSONB | TEXT |
UUID | CHAR(36) | UUID | TEXT |
| PK + 自動遞增 | INT ... AUTO_INCREMENT | SERIAL | INTEGER PRIMARY KEY AUTOINCREMENT |
主鍵搭配自動遞增這一列的方言差異最大。PostgreSQL 會把型別本身換成 SERIAL（內部其實是 INTEGER 加上序列），而 SQLite 則有一項規格上的限制：只有在欄位宣告為 INTEGER PRIMARY KEY 這種特定寫法時，才會成為真正的 rowid 別名而具備自動遞增。工具吸收了這三種方言的差異，依照您選擇的方言輸出正確的語法。
另外，設為主鍵的欄位即使指定了 NOT NULL、UNIQUE 或預設值也會被忽略，只輸出 <型別> PRIMARY KEY。因為主鍵在定義上本來就已經是 NOT NULL 且 UNIQUE。
從 JSON 範例推論欄位的邏輯
貼上 JSON 物件（或陣列）後，會從各屬性的值推論欄位型別。判定的優先順序大致如下：
- 值全為布林 →
BOOLEAN - 值全為數字 → 全部是整數則為
INTEGER（若有超過 2^31 的值則為BIGINT），含有小數則為DECIMAL - 值全為字串 → ISO 8601 日期時間格式為
DATETIME、日期格式為DATE、UUID 格式為UUID，其餘為VARCHAR（若有超過 255 字元的值則為TEXT） - 值全為物件 →
JSON
若以陣列傳入範例，會將多筆的值一併用於判定。如此便能偵測單筆資料無法得知的可為 NULL（值中是否混有 null）以及型別的差異（不只整數還混有小數等）。
[
{ "id": 1, "nickname": "Alice", "score": 10 },
{ "id": 2, "nickname": null, "score": 10.5 }
]在這個範例中，nickname 因為混有 NULL 而解除 NOT NULL，score 則因為整數與小數並存而被推論為 DECIMAL。
巢狀的物件陣列會拆分為關聯資料表
當頂層屬性是「物件的陣列」時，工具不會單純地將它收斂成 JSON 型別欄位，而是自動拆分為擁有外鍵指向父資料表的獨立資料表。
{
"id": 1,
"name": "Order #1",
"items": [
{ "product": "Widget", "qty": 2 },
{ "product": "Gadget", "qty": 1 }
]
}將這份 JSON 以 orders 為名產生時，除了 orders 資料表外還會建立 items 資料表，並自動設定 items.orders_id → orders.id 的外鍵關係。就像訂單與其明細那樣的一對多關係，可以從單一份 JSON 組建出來。巢狀超過兩層時不會自動拆分資料表，這種情況請在產生後手動調整。
透過 SQL 轉 ER 圖來回驗證設計
把在 DDL 產生器中建立的資料表結構以 MySQL 方言 DDL 匯出，再貼到 SQL 轉 ER 圖，就會解析出相同的資料表、欄位與關聯。這條來回路徑很適合用來確認產生的 DDL 是否為可正常解析的標準語法，或是日後重新檢視結構時使用。
常見問題
勾選 PK 後，NOT NULL、UNIQUE、預設值的設定會怎樣？
主鍵依定義即為 NOT NULL 且 UNIQUE，因此勾選 PK 的欄位會忽略 NOT NULL、UNIQUE、預設值設定，僅輸出「型別 PRIMARY KEY」（若開啟自動遞增則加上 AUTO_INCREMENT 等）。
產生的 DDL 可以直接用於正式環境的遷移嗎？
本工具的定位是資料表設計的初稿或審查資料。索引、CHECK 約束、字元集與定序、分區等正式營運所需的細節並未包含在內，因此產生後請務必檢查內容，並做必要的調整後再使用。
由 JSON 產生的資料表名稱與既有資料表重複時會怎樣？
會自動加上 _2 之類的流水號以避免重複，手動建立的既有資料表不會被覆寫。
如果對資料表設計毫無頭緒，不妨先貼上手邊的 JSON 範例試試看。
我們還提供其他實用的開發工具。
https://devtoolkits.app/