SQL CREATE TABLE Generator - Tạo Bảng SQL Từ JSON

Tính năng nổi bật

• Ghép câu lệnh CREATE TABLE hoàn chỉnh từ danh sách khóa của một object JSON
• Chuỗi ngắn ra VARCHAR(255), chuỗi dài quá 255 ký tự ra TEXT, chuỗi mở đầu bằng dạng ngày ra TIMESTAMP
• Số nguyên ra INTEGER, số thập phân ra DECIMAL(12,2), giá trị true/false ra BOOLEAN
• Mảng và object lồng nhau quy về kiểu cột JSON thay vì bị bỏ qua
• Trường tên id được viết thành id SERIAL PRIMARY KEY, tức khóa chính tự tăng theo lối PostgreSQL
• Mọi cột có giá trị trong mẫu đều được gắn NOT NULL, cột đang null thì để trống ràng buộc đó
• Ô tên bảng lọc ký tự lạ về dấu gạch dưới nên tên sinh ra luôn là định danh SQL hợp lệ
• Dán vào mảng thì lấy object đầu tiên làm mẫu, JSON hỏng thì hiện đúng thông báo lỗi phân tích

Có sẵn dữ liệu mẫu thì việc gõ danh sách cột là công việc máy nên làm

Tình huống quen thuộc: bạn nhận một file xuất từ hệ thống cũ, một response API, hoặc một khối JSON ai đó gửi qua tin nhắn, và việc cần làm là dựng một bảng để chứa đống đó. Bản thân việc thiết kế bảng cần suy nghĩ, nhưng bước đầu tiên thì hoàn toàn máy móc: đọc từng khóa, đặt tên cột, nhìn giá trị đoán kiểu, gõ dấu phẩy cho đúng, nhớ đừng để dấu phẩy thừa ở dòng cuối. Với ba mươi cột thì đây là mười lăm phút gõ chán và ít nhất một lần chạy lỗi cú pháp. Công cụ làm phần đó rồi trả về một câu lệnh chạy được ngay để bạn dựng bảng nháp trong cơ sở dữ liệu phát triển, nạp thử dữ liệu, xem truy vấn ra sao, rồi mới quyết định các thứ quan trọng: cột nào cần index, cột nào phải là khóa ngoại, độ dài VARCHAR bao nhiêu là hợp, cột nào thật ra nên tách sang bảng khác. Điểm cần nhắc là kết quả bám theo cú pháp PostgreSQL, và mỗi hệ quản trị lại có bảng kiểu riêng, nên trước khi chạy trên MySQL, SQLite hay SQL Server bạn cần sửa vài chỗ; phần dưới nói rõ những chỗ nào.

Lợi ích khi sử dụng

• •Có câu lệnh chạy được ngay thay vì gõ tay ba mươi dòng cột và dò lỗi dấu phẩy
• •Không phụ thuộc ORM nào nên dùng được cho dự án PHP, Go, Python hay bất kỳ ngôn ngữ nào
• •Kiểu cột được gợi ý theo giá trị thật nên phần lớn dòng chỉ cần xác nhận chứ không cần sửa
• •Dựng nhanh bảng nháp để thử truy vấn trước khi chốt thiết kế chính thức
• •Hữu ích khi cần chỗ đổ tạm một file dữ liệu lạ để soi bằng SQL thay vì mở bằng bảng tính
• •Chạy trong trình duyệt nên dữ liệu mẫu không rời khỏi máy bạn

Bốn bước và một lần rà soát trước khi chạy thật

1. 1Dán một bản ghi JSON đại diện vào ô bên trái, nên chọn bản ghi có giá trị dài nhất ở các trường chuỗi để công cụ không đoán thiếu độ dài.
2. 2Gõ tên bảng vào ô phía trên theo lối snake_case số nhiều như users, order_items; ký tự không hợp lệ sẽ tự đổi thành dấu gạch dưới.
3. 3Đọc lại từng dòng cột: soát độ dài VARCHAR, soát cột tiền có đang là DECIMAL không, soát cột NOT NULL nào thật ra được phép để trống.
4. 4Sửa cú pháp theo hệ quản trị bạn dùng nếu không phải PostgreSQL, chủ yếu là dòng khóa chính và kiểu BOOLEAN.
5. 5Chạy câu lệnh trong cơ sở dữ liệu phát triển trước, rồi bổ sung khóa ngoại, index, giá trị mặc định và ràng buộc CHECK bằng các câu lệnh ALTER TABLE hoặc CREATE INDEX riêng.

Bảng kiểu cột công cụ đang dùng và độ chính xác của từng suy đoán

Suy đoán ở đây dựa hoàn toàn vào giá trị trong mẫu nên có chỗ chắc chắn, có chỗ chỉ là phỏng đoán hợp lý. Chuỗi dưới 255 ký tự ra VARCHAR(255), chuỗi dài hơn ra TEXT, chuỗi mở đầu bằng dạng ngày YYYY-MM-DD ra TIMESTAMP. Số nguyên ra INTEGER, số thập phân ra DECIMAL(12,2), giá trị luận lý ra BOOLEAN, còn mảng và object ra JSON. Con số 255 trong VARCHAR là di sản từ MySQL đời cũ chứ không phải một chuẩn kỹ thuật, và trong PostgreSQL thì VARCHAR không giới hạn hay TEXT còn nhanh bằng hoặc hơn VARCHAR có giới hạn, nên nếu bạn chỉ chạy PostgreSQL thì đổi hết sang TEXT cũng không mất gì. Ngược lại, với các cột có ràng buộc thật về độ dài như mã bưu chính hay biển số thì nên đặt đúng con số nhỏ để cơ sở dữ liệu chặn giúp dữ liệu rác. DECIMAL(12,2) nghĩa là tối đa mười hai chữ số trong đó hai chữ số sau dấu thập phân, vừa đủ cho tiền Việt tới hàng chục tỷ nhưng thiếu cho tỷ giá hay đơn giá cần bốn chữ số lẻ, và cũng không đủ cho hệ thống ghi số tiền lớn hơn. Với TIMESTAMP có một lựa chọn quan trọng: PostgreSQL phân biệt TIMESTAMP không kèm múi giờ với TIMESTAMPTZ có kèm, và với ứng dụng có người dùng ở nhiều múi giờ thì gần như luôn nên dùng TIMESTAMPTZ. Cuối cùng, JSON nên đổi thành JSONB nếu bạn dùng PostgreSQL vì JSONB lưu dạng nhị phân, truy vấn nhanh hơn và đánh index được.

Khóa chính tự tăng viết khác nhau ở từng hệ quản trị

Dòng id SERIAL PRIMARY KEY chỉ chạy đúng trên PostgreSQL, và ngay cả ở đó nó cũng không còn là cách được khuyến nghị. SERIAL là lối viết tắt cũ, phía sau nó cơ sở dữ liệu tạo một sequence rồi gắn làm giá trị mặc định; cách hiện đại hơn từ PostgreSQL 10 trở đi là id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, theo chuẩn SQL, quản lý quyền gọn hơn và không để lại sequence mồ côi khi xóa cột. Chuyển sang MySQL hoặc MariaDB thì phải viết id INT AUTO_INCREMENT PRIMARY KEY, dùng SERIAL ở đó tuy không lỗi nhưng lại là bí danh của BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE, tức bạn nhận về một kiểu khác hẳn cái mình tưởng. SQLite dùng id INTEGER PRIMARY KEY AUTOINCREMENT và bắt buộc phải là INTEGER viết đủ chứ không phải INT. SQL Server viết id INT IDENTITY(1,1) PRIMARY KEY. Kiểu BOOLEAN cũng có chuyện tương tự: PostgreSQL có kiểu thật, MySQL chỉ coi BOOLEAN là bí danh của TINYINT(1) nên đọc ra là 0 và 1 chứ không phải true và false, còn SQLite không có kiểu luận lý và lưu thành số nguyên. Nếu bảng của bạn sẽ chứa nhiều bản ghi hoặc cần khóa không đoán được từ bên ngoài, hãy cân nhắc dùng BIGINT thay INTEGER, hoặc dùng UUID làm khóa chính và tự sinh ở tầng ứng dụng.

Cái bẫy tên cột viết hoa lẫn thường trong PostgreSQL

Đây là lỗi làm mất thời gian nhiều nhất với người mới chuyển từ tầng ứng dụng xuống làm việc trực tiếp với cơ sở dữ liệu. Công cụ chuyển tên khóa JSON sang dạng camelCase, nên khóa created_at trở thành cột createdAt trong câu lệnh. Vấn đề là PostgreSQL tuân theo chuẩn SQL ở chỗ mọi định danh không đặt trong dấu nháy kép đều bị hạ hết về chữ thường. Câu lệnh tạo bảng của bạn chạy trót lọt, nhưng cột thật sự nằm trong cơ sở dữ liệu lại tên là createdat viết liền không hoa. Sau đó bạn viết SELECT createdAt FROM users thì vẫn chạy, vì nó cũng bị hạ về chữ thường và khớp; nhưng khi một thư viện hay công cụ nào đó sinh câu lệnh có đặt nháy kép quanh tên cột theo đúng dạng camelCase, thì cơ sở dữ liệu tìm chính xác chuỗi chữ đó và báo không tồn tại cột. Cách xử lý dứt điểm là đừng chống lại quy ước: đổi hết tên cột về snake_case chữ thường trước khi chạy, tức created_at, is_active, user_id, rồi để tầng ứng dụng lo việc ánh xạ sang camelCase. Cách thứ hai là bọc tên cột trong nháy kép ở mọi nơi để giữ nguyên chữ hoa, nhưng như vậy bạn phải nhớ bọc suốt đời, quên một chỗ là lỗi. MySQL trên Linux thì phân biệt hoa thường ở tên bảng nhưng không ở tên cột, thêm một lý do nữa để cứ dùng snake_case cho mọi thứ.

Khóa ngoại, index và ràng buộc: phần dữ liệu mẫu không bao giờ nói ra

Câu lệnh sinh ra mới chỉ định nghĩa chỗ chứa dữ liệu, chưa định nghĩa luật của dữ liệu, mà phần luật mới là thứ giữ cho cơ sở dữ liệu không mục nát sau vài tháng. Có ba nhóm cần thêm tay. Nhóm thứ nhất là khóa ngoại: một cột tên customer_id chứa số 42 thì trong mẫu nó chỉ là số nguyên, chỉ có bạn mới biết nó phải trỏ tới bảng customers, và khai báo REFERENCES customers(id) sẽ chặn việc chèn một mã khách không tồn tại. Đi kèm là hành vi khi xóa bản ghi cha, ON DELETE CASCADE xóa lan, RESTRICT chặn không cho xóa, SET NULL để trống; chọn đại là cách nhanh nhất để hoặc mất dữ liệu hoặc để lại bản ghi mồ côi. Nhóm thứ hai là index: cơ sở dữ liệu chỉ tự tạo index cho khóa chính và cột UNIQUE, còn mọi cột bạn hay dùng trong mệnh đề WHERE, JOIN hay ORDER BY thì phải tự tạo, và với index nhiều cột thì thứ tự cột quyết định index có được dùng hay không. Nhóm thứ ba là ràng buộc giá trị: UNIQUE cho email, DEFAULT now() cho cột thời điểm tạo, DEFAULT true cho cột trạng thái, CHECK (price >= 0) để chặn số âm ngay tại cơ sở dữ liệu thay vì chỉ kiểm ở tầng ứng dụng. Cũng cần soát lại các NOT NULL mà công cụ gắn cho mọi cột có giá trị: nhiều cột thực tế được phép trống, giữ nguyên NOT NULL sẽ làm mọi lệnh chèn thiếu trường đó thất bại.

Nên dùng trang này hay hai trang sinh schema còn lại

Ba công cụ cùng nhận JSON nhưng đầu ra phục vụ ba tầng và không thay thế nhau được. Trang này cho ra DDL thuần, tức thứ chạy trực tiếp trong psql, DBeaver, phpMyAdmin hay bất kỳ công cụ quản trị nào, không phụ thuộc ngôn ngữ hay framework. Chọn nó khi dự án không dùng ORM, khi bạn viết migration bằng SQL tay, khi cần điều khiển chính xác kiểu cột và ràng buộc, hoặc đơn giản khi cần dựng nhanh một bảng để đổ dữ liệu vào soi. Trang /vi/tools/prisma-schema-generator cho ra khối model của file schema.prisma, tức bạn mô tả bằng ngôn ngữ của ORM rồi để Prisma sinh SQL và quản lý lịch sử migration; chọn nó khi dự án Node hoặc Next.js đã dùng Prisma, vì lúc đó viết DDL tay sẽ làm lệch với mô hình mà ORM đang giữ. Trang /vi/tools/zod-schema-generator nằm ở tầng hoàn toàn khác: nó sinh schema kiểm tra dữ liệu lúc chạy cho TypeScript, chặn payload sai ngay khi vào ứng dụng, không tạo bảng và không biết gì về cơ sở dữ liệu. Các trang láng giềng nên biết: /vi/tools/database-schema-designer khi cần phác toàn bộ mô hình nhiều bảng và quan hệ trước, /vi/tools/csv-to-sql-insert để sinh lệnh INSERT nạp dữ liệu vào bảng vừa tạo, /vi/tools/sql-formatter để căn lại câu lệnh dài cho dễ đọc trước khi đưa vào kho mã, và /vi/tools/db-connection-string-parser khi cần đọc hoặc dựng chuỗi kết nối tới máy chủ.

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

Từ khóa liên quan

• sql create table generator
• json to sql table
• tạo bảng sql từ json
• create table online
• sql ddl generator
• postgresql create table
• mysql create table
• sqlite create table
• serial primary key postgresql
• auto_increment mysql
• kiểu dữ liệu sql varchar text
• timestamptz postgresql
• jsonb postgresql
• khóa ngoại foreign key sql
• index sql khi nào cần
• ràng buộc check unique default
• decimal cho cột tiền tệ
• thiết kế bảng database từ dữ liệu mẫu