跳至內容
資料庫設計

DDL 產生器

以視覺化方式設計資料表,同時產生 CREATE TABLE 語句(MySQL / PostgreSQL / SQLite)與 ER 圖。也可以貼上 JSON 範例自動推論欄位。所有處理皆在瀏覽器內完成,您輸入的內容不會被傳送。

指南: 使用方式與特色

  • 在「由 JSON 自動產生」貼上物件或陣列 JSON,即可新增已自動推論欄位型別、主鍵、NOT NULL 的資料表。
  • 在「資料表設計」中可直接編輯資料表名稱、欄位名稱、型別、PK/NOT NULL/UNIQUE/自動遞增與預設值。
  • 在「關聯」中選擇來源資料表/欄位與目標資料表/欄位,即可新增外鍵約束並在 ER 圖中顯示連接線。
  • 選擇資料庫方言(MySQL / PostgreSQL / SQLite)並點擊「產生 DDL」,即可取得該方言格式的 CREATE TABLE 語句。

FAQ: 常見問題

  • MySQL、PostgreSQL、SQLite 之間的型別如何轉換?

    資料表在內部以共通的邏輯型別(INTEGER、DECIMAL、VARCHAR 等)管理,只有在產生 DDL 時才會轉換為各資料庫實際的型別。例如 BOOLEAN 在 SQLite 中會轉換為 INTEGER(因為 SQLite 沒有布林型別),自動遞增主鍵在 MySQL 會輸出 AUTO_INCREMENT、PostgreSQL 為 SERIAL、SQLite 則為 INTEGER PRIMARY KEY AUTOINCREMENT。
  • 勾選 PK 後,NOT NULL、UNIQUE、預設值的設定會怎樣?

    主鍵依定義即為 NOT NULL 且 UNIQUE,因此勾選 PK 的欄位會忽略 NOT NULL、UNIQUE、預設值設定,僅輸出「型別 PRIMARY KEY」(若開啟自動遞增則加上 AUTO_INCREMENT 等)。
  • 由 JSON 產生時,巢狀資料會如何處理?

    若頂層屬性的值為物件陣列,會自動拆分成擁有外鍵指向父資料表的獨立資料表(例如訂單與明細)。單純的巢狀物件則會轉為 JSON 型別欄位。超過一層的巢狀不會自動拆分,需要手動調整。

使用情境: 常見使用情境

  • 為新 API 或服務規劃初始資料表

    在專案初期以視覺化方式組合所需的資料表與欄位,並直接匯出為 CREATE TABLE 語句。

  • 從既有 JSON 回應反推資料庫結構

    貼上 API 回應或日誌的 JSON 範例,自動產生對應的資料表結構與 DDL 草稿。

  • 製作團隊 ER 圖審查資料

    設計好的資料表結構可立即以 Mermaid 格式的 ER 圖呈現與分享,方便審查時對齊設計共識。

  • 結合 sql-to-er/SQL Builder 的完整設計流程

    將產生的 DDL 交給 SQL Builder 開始組建查詢,或之後貼回 sql-to-er 再次確認結構,從設計到查詢都能在瀏覽器內完成。

注意: 注意事項與限制

  • 產生的 DDL 僅包含基本約束

    支援 PRIMARY KEY、NOT NULL、UNIQUE、DEFAULT、FOREIGN KEY,但不會產生索引、CHECK 約束、字元集/定序、分區等設定。在用於正式環境遷移前,請務必檢查產生的內容。

  • JSON 型別推論取決於您提供的範例

    型別只能根據您提供範例中出現的值來推論。若欄位實際上可能出現其他型別的值,請在產生後手動調整型別。

由 JSON 自動產生(選用)

資料表設計

關聯(外鍵)

DDL 輸出

ER 圖預覽

這個工具的相關文章

最新文章

使用案例
2026-08-07

curl 選項速查|-X、-H、-d 實際做了什麼與常見陷阱

整理實務上會遇到的 curl 選項:為什麼加了 -d 就已經是 POST、-d 與 --data-raw 的差別、開頭的 @ 會悄悄讀取檔案的陷阱、單引號與雙引號的取捨,以及為什麼 -k 和 -L 值得多想一下。

工具介紹
2026-08-06

JSON Schema 與 Zod 雙向轉換的原理|required 與 .optional() 的對應

解析雙向轉換器的實作:把 JSON Schema 轉成 Zod 結構定義,也把 Zod 程式碼轉回 JSON Schema。內容涵蓋 required 與 .optional() 預設值相反的陷阱、限制條件對照表,以及不執行程式碼就完成剖析的做法。

使用案例
2026-08-06

SQL 子句執行順序參考|為什麼 WHERE 看不到 SELECT 的別名

SQL 並不是照您撰寫的順序執行。以邏輯執行順序(FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT)為主軸,說明別名為何在 WHERE 無法使用、WHERE 與 HAVING 的分工、ONLY_FULL_GROUP_BY、COUNT(*) 與 COUNT(欄位) 的差異,以及 LEFT JOIN 搭配 WHERE 的陷阱。

使用案例
2026-08-06

unified diff 格式閱讀指南|看懂 git diff 的 @@ 標頭

說明如何閱讀 git 產生的 unified diff 格式:@@ -12,7 +12,9 @@ 四個數字的意義、只改一個字元為何顯示成整行替換、空白與換行字元的陷阱、\ No newline at end of file、合併提交的 @@@ 組合式 diff,以及以 similarity index 推斷檔案更名。

使用案例
2026-08-06

UTC⇄JST 換算參考手冊|9小時時差對照表與時區踩雷指南

以對照表整理 UTC 與日本時間(JST)的換算,並說明與台灣時間(UTC+8)相差 1 小時的關係。內容涵蓋 ISO 8601 的 Z 與 +09:00、JavaScript 日期解析悄悄位移 9 小時的條件、MySQL/PostgreSQL 的時區行為,以及 GitHub Actions cron 一律以 UTC 執行的陷阱。

使用案例
2026-08-04

CREATE TABLE 參考手冊|MySQL、PostgreSQL、SQLite 的型別與約束差異

以跨資料庫對照表整理 CREATE TABLE(DDL)的寫法:型別對應表、自動編號(AUTO_INCREMENT / IDENTITY / rowid)的方言差異、外鍵的 ON DELETE 行為,以及 MySQL 會靜默忽略的 CHECK 約束。

廣告

廣告