CSV 轉 SQL

CSV 轉 SQL 做的事情很具體：拿一份用逗號分隔的表格文字，輸出能在關聯式資料庫裡重現這份資料的 SQL 語句。通常會產出一段 `CREATE TABLE`（按 CSV 表頭定義欄位）和一組 `INSERT`（把每一列資料放進表裡）。這份 SQL 是一份「可讀、可改、可跑」的起點稿，不是經過 DBA 評審、已經和生產資料庫對齊的遷移腳本。把它當「草稿」看，後面的事才不會做反。

為什麼會需要這一步轉換

CSV 是电子表格、导出数据、临时倾出文件的通用语言；数据库说的是 SQL。当一份行列文件要变成可以被其它查询 JOIN 的真实表时，就得有人来搭这座桥。给五十行手敲 INSERT 既费时间又容易把引号写错；用工具自动生成一版、再人工审阅修改，往往比纯手写快、也更不容易出现“某一行字符串没转义”的低级错。

工具不得不「猜」的時候，遵循哪些規則

CSV 没有 schema、没有类型系统，转换工具必须替你做几个决定。提前知道这些规则，审查输出会快很多。

• 欄位名來自表頭列：含空白、連字號或保留字時會被加引號變成合法識別字。
• 型別按前幾列採樣推斷：整欄都是數字就猜整數，都是小數就猜浮點，其它情況一律退回到文字。
• 空单元格默认变成 `NULL`，除非整列明显就是文本而且确实存在“真空字符串”这种合法值。
• 值里的单引号会按 SQL 规则用两个单引号转义：`O'Brien` 会变成 `'O''Brien'`，避免插入语句被引号截断。
• 数字和布尔不加引号，其它一律按字符串字面量加引号。原本看起来像数字但应当当作文本存（例如订单号 `00123`）的列，要在审查阶段显式标出来。

一句話原則：工具保證產生的 SQL「能編譯」，不保證推斷出來的 schema 和真實應用對齊。`CREATE TABLE` 的最終決定權永遠在審稿的你手上。

如何使用這個工具

1. 先在 CSV 轉 SQL 中准备一份有代表性的需要產生建表或插入 SQL 的 CSV 行資料，不要一开始就處理最大或最敏感的真实内容。
2. 执行處理流程并產生按照 CSV 表头和行值映射出来的 SQL 草稿后，優先檢查表头清洁度、分隔符准确性、引号、空儲存格、推断列類型和行一致性，再判断结果是否真的可用。
3. 只有当结果已经適合用于匯入審查、Mock 資料准备、迁移规划和表格到資料库交接，并且不再触发這条风险提醒时，才複製或下载輸出：如果 CSV 里存在异常分隔符或带引号逗号，必须先修正，再信任產生出来的 SQL。

CSV 轉 SQL 範例

這個 CSV 轉 SQL 示例使用有代表性的需要產生建表或插入 SQL 的 CSV 行資料，展示產生后的按照 CSV 表头和行值映射出来的 SQL 草稿，便于你先確認表头清洁度、分隔符准确性、引号、空儲存格、推断列類型和行一致性，再把同样設定用于真实輸入。

範例輸入

[{"id":1,"name":"Ada","active":true}]

預期輸出

CREATE TABLE items (id INTEGER, name TEXT, active BOOLEAN);
INSERT INTO items (id, name, active) VALUES (1, "Ada", TRUE);

一份四列 CSV 與對應的 SQL

-- CSV 输入
id,name,price,inStock
1,Notebook,4.50,true
2,Pen,1.20,false
3,Mug,7.00,true

-- 生成的 SQL（草稿）
CREATE TABLE products (
  id        INTEGER,
  name      TEXT,
  price     REAL,
  inStock   BOOLEAN
);

INSERT INTO products (id, name, price, inStock) VALUES (1, 'Notebook', 4.50, true);
INSERT INTO products (id, name, price, inStock) VALUES (2, 'Pen',      1.20, false);
INSERT INTO products (id, name, price, inStock) VALUES (3, 'Mug',      7.00, true);

注意：產生的表裡沒有主鍵、沒有 `NOT NULL` 約束、沒有索引。工具不會替你「順手補上」這些——它們是只有你能決定的契約。

什麼場景下 CSV 轉 SQL 最合適

这一步转换最划算的场景，是目标本来就是“草稿数据库 / 一次性导入 / 方案讨论的起点”——任何需要快速回答“这份 CSV 大概能不能变成一张表”的位置。

• 把一份小型參考資料（國家、幣種、商品類目）灌進一個全新的開發資料庫。
• 拿产品/QA 维护的表格作为测试 fixture 的起点，先生成 SQL 再调整。
• 和同事讨论 schema：“这是 CSV 的样子，这是它会生成的 SQL，咱们要改哪里？”
• 在 SQLite 或 Postgres 沙盒里跑一次性导入：5 分钟内把数据变成可 SQL 查询的形式。
• 评估第三方导出的数据能不能塞进现有表结构：先用 CSV 推一版草稿 schema，再去和现有 DDL 做 diff。

在執行產生 SQL 前應當處理的幾類坑

生成 SQL 在生产环境出事，多数不是工具错了，而是“拿生成稿当成品”。下面这些是把 SQL 粘进 `psql`、`sqlite3` 之前最值得复核的几类情况。

• 表頭與保留字撞名（`order`、`user`、`select`）：不同資料庫方言的跳脫符不一樣，且常常在遷移到另一種資料庫時才暴露。
• 类型不纯的列：原本应是数字的列里出现一行 `N/A`，整列就会被推成 `TEXT`，后续所有数值运算 SQL 都会跟着出错。
• 没有约定格式的日期字符串（如 `03/04/2024`）：在草稿里先按 `TEXT` 落地，避免数据库按错误时区/语言解析。
• 超长的单条 INSERT 列表：大多数数据库更适合用多值 `VALUES (...)`、`COPY`（Postgres）、`.import`（SQLite）等批量方式，而不是几千条独立 INSERT。
• 未包事务：大批量 INSERT 不包在事务里，一旦中途失败就是部分提交，回滚成本极高。在执行生成的脚本前手动加上 `BEGIN; ... COMMIT;`。
• 直接对生产库执行：哪怕数据看起来很无害，也务必先在 Staging 副本上跑一遍。

CSV 轉 SQL 與相鄰的「資料載入」方案對比

使用注意

• 複用按照 CSV 表头和行值映射出来的 SQL 草稿前，先檢查表头清洁度、分隔符准确性、引号、空儲存格、推断列類型和行一致性。
• 如果 CSV 里存在异常分隔符或带引号逗号，必须先修正，再信任產生出来的 SQL。
• 当结果会影响生产工作或客户可见内容时，應保留原始需要產生建表或插入 SQL 的 CSV 行資料以便回退和核对。

CSV 轉 SQL 參考說明

CSV 轉 SQL 的参考說明應始终围绕需要產生建表或插入 SQL 的 CSV 行資料、產生的按照 CSV 表头和行值映射出来的 SQL 草稿，以及用于匯入審查、Mock 資料准备、迁移规划和表格到資料库交接前必须確認的檢查点。

• 輸入重点：需要產生建表或插入 SQL 的 CSV 行資料。
• 輸出重点：按照 CSV 表头和行值映射出来的 SQL 草稿。
• 複核重点：表头清洁度、分隔符准确性、引号、空儲存格、推断列類型和行一致性。

參考資料

• RFC 4180: Common Format and MIME Type for CSV Files
• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax