Bộ chuyển đổi SQL sang JSON miễn phí

Chuyển đổi câu lệnh SQL CREATE TABLE sang lược đồ JSON. Trích xuất tức thì tên cột, kiểu và ràng buộc.

Dữ liệu của bạn không bao giờ rời khỏi thiết bị

Về chuyển đổi SQL → JSON

Công cụ này phân tích các câu lệnh SQL CREATE TABLE và chuyển đổi chúng sang định dạng lược đồ JSON. Nó trích xuất tên cột, kiểu dữ liệu (INT, VARCHAR, TEXT, BOOLEAN, DATE, TIMESTAMP, DECIMAL) và ràng buộc (NOT NULL, PRIMARY KEY, giá trị DEFAULT). Đầu ra JSON phù hợp cho tài liệu API, thiết kế cơ sở dữ liệu hoặc các công cụ di chuyển.

Kiểu dữ liệu SQL được hỗ trợ

Câu hỏi thường gặp

Những dialect SQL nào được hỗ trợ?

Trình chuyển đổi này xử lý cú pháp SQL chuẩn được sử dụng bởi MySQL, PostgreSQL, SQL Server và SQLite. Các tính năng đặc thù của dialect có thể không được nhận diện đầy đủ.

Nó có xử lý các ràng buộc phức tạp không?

Trình chuyển đổi nhận diện NOT NULL, PRIMARY KEY, DEFAULT và thông tin kiểu cơ bản. Các ràng buộc phức tạp như CHECK hoặc FOREIGN KEY được lưu dưới dạng chú thích văn bản.

Tôi có thể sử dụng đầu ra JSON trực tiếp không?

Có! Đầu ra JSON được định dạng để dễ đọc và có thể được sử dụng trong các lược đồ API, giao diện TypeScript hoặc trình tạo tài liệu.

Schema, không phải dữ liệu, đây là chức năng của công cụ này

Converter này nhận câu lệnh SQL CREATE TABLE và xuất ra JSON Schema: mô tả các cột, kiểu dữ liệu và ràng buộc cơ bản, phù hợp cho hợp đồng API, tạo kiểu TypeScript và di chuyển document-store. Nó không chuyển đổi các hàng INSERT hoặc tập kết quả truy vấn sang JSON. Sự quan tâm về «SQL to JSON» trong tìm kiếm phân chia gần như đều nhau giữa hai nhu cầu đó; nếu bạn đến đây với kỳ vọng chuyển đổi hàng-sang-đối-tượng, bạn sẽ cần một công cụ khác. Đường dẫn chuyển đổi schema là trường hợp hướng đến lập trình viên: bạn có một định nghĩa bảng và muốn có mô tả có cấu trúc về hình dạng của nó mà một công cụ khác có thể tiêu thụ.

Lịch Sử Ngắn Gọn Về SQL

SQL được thiết kế tại Phòng Thí Nghiệm Nghiên Cứu San Jose của IBM vào đầu những năm 1970 bởi Donald D. Chamberlin và Raymond F. Boyce. Tên gốc là SEQUEL: Structured English Query Language, được hình thành như một giao diện cấp cao hơn cho hệ thống cơ sở dữ liệu quan hệ thử nghiệm System R của IBM. Mô hình quan hệ đã được Edgar F. Codd công bố năm 1970; đóng góp của Chamberlin và Boyce là một cú pháp mà các nhà phân tích thông thường có thể đọc, được mô phỏng theo các mệnh đề tiếng Anh tự nhiên (SELECT … FROM … WHERE …) thay vì các ký hiệu đại số của Codd. Boyce (người cũng đặt tên cho Dạng Chuẩn Boyce-Codd) qua đời năm 1974 ở tuổi 26, trước khi ngôn ngữ mà ông đồng phát minh được phát hành thương mại. Tên được đổi thành SQL năm 1975 do mâu thuẫn nhãn hiệu với nhãn hiệu SEQUEL của Hawker Siddeley, mặc dù cách phát âm «sequel» gốc vẫn tồn tại ở Hoa Kỳ bên cạnh cách phát âm quốc tế «ess-cue-ell».

ANSI đã chuẩn hóa SQL vào năm 1986 (SQL-86), ISO phê chuẩn phiên bản gần như giống hệt vào năm 1987 dưới dạng ISO/IEC 9075, và tiêu chuẩn đã được sửa đổi mỗi ba đến năm năm kể từ đó: SQL-92 (vẫn là cơ sở mà hầu hết các hướng dẫn giả định), SQL:1999 (truy vấn đệ quy, trigger), SQL:2003 (kiểu XML, MERGE), SQL:2011 (bảng thời gian), SQL:2016 (hỗ trợ JSON) và mới nhất là SQL:2023 (mảng đa chiều, truy vấn đồ thị thuộc tính). Dù có nhiều công nghệ cạnh tranh (cơ sở dữ liệu đối tượng trong những năm 1990, NoSQL vào cuối những năm 2000, data lake trong những năm 2010), SQL vẫn tồn tại như ngôn ngữ truy vấn thống trị cho dữ liệu có cấu trúc hơn năm mươi năm. Đến năm 2024, ngay cả hầu hết các nền tảng NoSQL cũng đã giới thiệu lại SQL hoặc các lớp giống SQL (CQL của Cassandra, giai đoạn tổng hợp $sql của MongoDB, PartiQL của DynamoDB, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), xác nhận dự đoán của Mike Stonebraker rằng ngôn ngữ này sẽ sống lâu hơn bất kỳ engine lưu trữ nào.

JSON Trong Một Đoạn Văn

JSON (JavaScript Object Notation) được Douglas Crockford đặc tả vào năm 2001, xuất phát từ một tập con của cú pháp literal đối tượng JavaScript, và được chuẩn hóa dưới dạng ECMA-404 vào năm 2013 và IETF RFC 8259 vào năm 2017. Nó chỉ có sáu kiểu giá trị (string, number, boolean, null, array, object) và không có khái niệm gốc về ngày tháng, số thập phân, nhị phân hay schema. JSON Schema (một đặc tả riêng, hiện tại ở bản thảo 2020-12) xếp lớp xác thực cấu trúc và kiểu dữ liệu lên trên. Giá trị của JSON Schema đối với converter này: đây là định dạng di động, không phụ thuộc schema mà hầu hết mọi thư viện tạo code và xác thực hiện đại đều hiểu.

Quá Trình Chuyển Đổi Cơ Học

Ví dụ đầu vào điển hình:

CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  signup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  is_active BOOLEAN DEFAULT TRUE
);

Tương đương với:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "users",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "maxLength": 255 },
    "signup_at": { "type": "string", "format": "date-time" },
    "is_active": { "type": "boolean", "default": true }
  },
  "required": ["id", "email"]
}

Từng bước: tokenize đầu vào, xác định CREATE TABLE và tên bảng, tìm danh sách cột được đặt trong ngoặc đơn, chia các định nghĩa cột theo dấu phẩy cấp cao nhất (tôn trọng các dấu ngoặc lồng nhau cho những trường hợp như DECIMAL(10,2) hoặc CHECK (x > 0)), phân tích mỗi cột thành tên + kiểu + modifier, và ánh xạ kiểu SQL sang kiểu JSON Schema gần nhất. NOT NULL trở thành thành viên trong mảng required. DEFAULT trở thành giá trị default. PRIMARY KEY thường trở thành chú thích hoặc thành viên trong required. CHECK, FOREIGN KEY, UNIQUE và các chỉ mục thường trở thành chú thích văn bản vì JSON Schema không có tương đương trực tiếp.

Vấn Đề Phương Ngữ

SQL nổi tiếng là một họ các phương ngữ, không phải một ngôn ngữ duy nhất. Ngay cả cách đặt dấu định danh cơ bản cũng khác nhau:

Tên kiểu cũng khác nhau. INT(11) trong MySQL là gợi ý về độ rộng hiển thị mà PostgreSQL từ chối. SERIAL trong PostgreSQL là viết tắt của INT NOT NULL AUTO_INCREMENT PRIMARY KEY; IDENTITY đảm nhiệm vai trò tương tự trong SQL Server; SQLite dùng AUTOINCREMENT. BOOLEAN là TINYINT(1) ẩn dưới trong MySQL. Các kiểu địa lý (GEOMETRY, POINT), kiểu cột JSON (JSON, JSONB), kiểu mảng (INTEGER[] của PostgreSQL) và kiểu vector full-text (VECTOR(1536) trong pgvector) không có tương đương trong JSON Schema và sẽ trở thành chú thích chuỗi mờ đục. Dữ liệu nhị phân BLOB và BYTEA không có biểu diễn JSON gốc; thông lệ chuẩn là base64-stringification kèm gợi ý contentEncoding.

Kiểu Dữ Liệu SQL vs JSON, Sự Không Tương Thích

SQL có hệ thống kiểu dữ liệu phong phú; JSON chỉ có sáu kiểu giá trị và không có schema. Cần biết:

Khi Nào Bạn Cần Công Cụ Này

Các Phương Án Thay Thế Hiện Đại

Câu Hỏi Thêm

Nếu câu lệnh CREATE TABLE của tôi có ràng buộc FOREIGN KEY thì sao?

JSON Schema không có khái niệm foreign-key gốc. Biểu diễn gọn gàng nhất là một chú thích tùy chỉnh (ví dụ: thuộc tính x-foreign-key không chuẩn) ghi lại bảng và cột được tham chiếu. Converter này bảo toàn mối quan hệ dưới dạng ghi chú văn bản trong đầu ra; nếu bạn cần mô hình tham chiếu đầy đủ chính thức, $ref của JSON Schema cộng với khối định nghĩa riêng là lựa chọn gần nhất, nhưng khá lủng củng với các trường hợp nhiều-nhiều. Để mô hình quan hệ phong phú hơn, hãy xem xét DBML hoặc Atlas HCL.

Tại sao đầu ra không bao gồm ràng buộc CHECK?

JSON Schema có thể biểu diễn nhiều ràng buộc CHECK đơn giản, CHECK (age >= 0) trở thành {"minimum": 0}, CHECK (status IN ('a','b')) trở thành {"enum": ["a","b"]}: nhưng các biểu thức SQL tùy ý trong mệnh đề CHECK (gọi hàm, join, subquery) không có tương đương JSON Schema. Converter nhận diện các trường hợp đơn giản và bảo toàn các ràng buộc phức tạp dưới dạng chú thích văn bản thay vì âm thầm loại bỏ chúng.

Tôi có thể chuyển đổi các hàng INSERT sang JSON không?

Không được, công cụ này chỉ xử lý chuyển đổi ở cấp schema (CREATE TABLE). Để chuyển đổi ở cấp hàng, cách tiếp cận đúng thường là gốc từ cơ sở dữ liệu: SELECT row_to_json(t) FROM tbl t của PostgreSQL, JSON_OBJECT() của MySQL, hoặc xuất sang CSV và dùng công cụ CSV-to-JSON. mysqldump --xml được pipe qua converter XML-to-JSON là một đường đi quen thuộc khác.

Tại sao BIGINT lại là vấn đề trong JSON?

JSON.parse của JavaScript dùng IEEE 754 double, chỉ có thể biểu diễn chính xác các số nguyên lên đến 2^53 = 9.007.199.254.740.992. Các số vượt quá đó sẽ mất độ chính xác. BIGINT của SQL đi lên đến 2^63 ≈ 9,2 quintillion, vượt xa phạm vi số nguyên JSON an toàn. Quy ước đa nền tảng để vận chuyển BIGINT an toàn qua JSON là serialize dưới dạng chuỗi và parse với BigInt ở đích; nhiều API (tweet ID của Twitter / X, Stripe ID, bigserial của PostgreSQL) làm chính xác điều này.

Có dữ liệu nào được gửi đến máy chủ không?

Không. Parser chạy trong trình duyệt của bạn; đầu ra JSON được xây dựng cục bộ. SQL đã dán vào không bao giờ rời khỏi thiết bị của bạn, điều này quan trọng nếu câu lệnh CREATE TABLE của bạn chứa tên cột độc quyền, quy ước bảng nội bộ hoặc các chi tiết khác mà bạn không muốn ghi lại. Trang hoạt động offline sau khi đã tải.

Công cụ liên quan

Trình định dạng JSON

Định dạng, nén và xác thực JSON tức thì.

Trình định dạng SQL

Định dạng và làm đẹp các truy vấn SQL.

Trình định dạng XML

Định dạng và xác thực tài liệu XML.