คู่มือการใช้งาน SQL Schema Visualizer: แปลงคำสั่ง CREATE TABLE เป็น ER Diagram

ฐานข้อมูลทุกตัวเริ่มต้นจากข้อความล้วน ๆ ไม่ว่าจะเป็นไฟล์ migration หรือ DDL script ที่เต็มไปด้วยคำสั่ง CREATE TABLE ซึ่งบอกรายละเอียด column, data type และ key ของแต่ละ table การอ่านโค้ดพวกนี้แล้วจัดโครงสร้างขึ้นมาในหัวเองช้ามาก และยิ่ง schema ใหญ่ก็ยิ่งช้า SQL Schema Visualizer กลับภาระนี้ให้เครื่องมือทำ — เพียงวางคำสั่ง CREATE TABLE แล้วเห็น schema ถูกวาดเป็น ER diagram ภายในไม่กี่วินาที

ภาพช่วยได้จริงเพราะตัดเรื่อง "ตามหา" ออกไปทั้งหมด แทนที่จะไล่สแกนหาทุก clause ของ FOREIGN KEY แล้วพยายามจำว่า column ไหนชี้ไปที่ไหน คุณแค่เดินตามเส้นที่ลากไว้ระหว่างกล่อง table และเห็น join path รวมถึง reference ที่หลุดโยงกันได้ในทันที

เครื่องมือนี้ฟรีและทำงานในเบราว์เซอร์ทั้งหมด DDL ของคุณไม่เคยออกจากเครื่อง ไม่ต้องสมัครบัญชี และการแสดงผลเกิดขึ้นทันที คู่มือนี้จะพาไปดูฟีเจอร์ ขั้นตอนการใช้งานทีละข้อ parser อ่าน DDL ของคุณอย่างไร และสถานการณ์แบบไหนที่ diagram แบบนี้คุ้มค่าที่สุด

ทำไมต้องใช้ SQL Schema Visualizer?

• ภาพเร็วกว่าตัวหนังสือ: กล่อง table บวกเส้นความสัมพันธ์สื่อสารโครงสร้างได้เร็วกว่า DDL ดิบ ๆ มาก โดยเฉพาะ schema ที่คุณไม่ใช่คนเขียนเอง
• Feedback ทันทีขณะออกแบบ: แก้ column วางใหม่ แล้ว diagram อัปเดตทันที เป็น loop ที่เร็วมากสำหรับการไล่ระดับการออกแบบ data model
• จับ design smell ได้ก่อน: foreign key ที่หายไปและ table ที่ไม่เชื่อมกับใครเลยมองเห็นได้ด้วยตา ก่อนที่มันจะกลายเป็นปัญหา migration ในอนาคต
• ไม่ต้องติดตั้งอะไรเลย: ไม่มีโปรแกรมให้ลง ไม่มีบัญชีให้สมัคร เปิดหน้าเว็บ วาง DDL แล้ว diagram ก็ปรากฏ
• เป็นส่วนตัวโดยดีไซน์: การ parse เกิดขึ้นฝั่ง client ล้วน ๆ schema ที่เป็นความลับหรือเกี่ยวกับลูกค้าจึงอยู่บนเครื่องคุณเท่านั้น
• ใช้ฟรี: ไม่มีค่าใช้จ่าย และใช้ต่อได้แม้ออฟไลน์เมื่อโหลดหน้าเว็บแล้ว

ฟีเจอร์หลัก

จุดที่น่าสังเกตเพิ่มเติม:

• เส้นความสัมพันธ์คือหัวใจของเครื่องมือ เพราะมันเปลี่ยนรายชื่อ table ให้กลายเป็นแผนที่ที่บอกได้ทันทีว่า table ไหนอ้างอิง table ไหน
• Layout ยังอ่านง่าย แม้มีหลาย table คุณจึงวางไฟล์ migration ทั้งไฟล์ได้ ไม่ต้องเลือกเฉพาะบางส่วน
• Data type ไปพร้อมกับ column ทำให้ diagram ใช้เป็น data dictionary แบบย่อมือระหว่างประชุมได้ด้วย

วิธีใช้งาน

1. เปิดเครื่องมือ: เข้าไปที่หน้า SQL Schema Visualizer ในเบราว์เซอร์ของคุณ
2. คัดลอก DDL: หยิบคำสั่ง CREATE TABLE จากไฟล์ migration, ไฟล์ dump หรือเอกสาร schema ของทีม
3. วางลงในตัว editor: diagram จะแสดงผลทันที — table แต่ละตัวกลายเป็นกล่องที่มีรายชื่อ column อยู่ข้างใน
4. ตรวจ key: ยืนยันว่า primary key ถูกทำเครื่องหมาย และทุก clause ของ FOREIGN KEY มีเส้นเชื่อมไปยัง table ที่ถูกอ้างอิง
5. ปรับและแชร์: แก้ DDL วางใหม่ แล้วนำ diagram ล่าสุดไปใช้ใน design review, ticket หรือเอกสาร onboarding

จาก DDL สู่ ER Diagram

ถ้ารู้ว่า parser อ่านอะไร คุณจะเขียน DDL ที่ให้ diagram ถูกต้องได้ง่ายขึ้น

สิ่งที่ถูก parse เครื่องมืออ่านคำสั่ง CREATE TABLE แล้วดึงชื่อ table, ทุก column พร้อม data type, column ที่ประกาศด้วย PRIMARY KEY (ทั้งแบบ inline และแบบ table constraint) และ foreign key ที่เขียนแบบ FOREIGN KEY (column) REFERENCES other_table (column) จากนั้นสร้างเป็นกล่อง table พร้อม column ข้างใน และหนึ่งเส้นความสัมพันธ์ต่อหนึ่ง foreign key

ทำไมเส้น FK ถึงสำคัญที่สุด เส้น foreign key เผยให้เห็น join path ที่ reviewer ตามหา เมื่อ orders.customer_id อ้างอิง customers.customer_id เส้นระหว่างสองกล่องบอกคุณทันทีว่า join คู่นี้ใช้ได้จริง และ table ไหนเป็นฝั่งแม่ ส่วนเส้นที่ "หายไป" ก็มีประโยชน์ไม่แพ้กัน — table ที่ไม่มีใครอ้างอิงและไม่อ้างอิงใครมักเป็นคำถามแรกในการรีวิว

วิธีอ่าน diagram แต่ละกล่องคือหนึ่ง entity: ส่วนหัวคือชื่อ table ส่วนเนื้อในระบุ column โดย primary key ถูกไฮไลต์ไว้ เส้นความสัมพันธ์ใช้ crow's foot notation ซึ่งเป็นมาตรฐานของ ER diagram: ขีดเดียวคือฝั่ง "หนึ่ง" และอุ้งเท้าสามง่ามคือฝั่ง "หลาย" ใน schema ลูกค้ากับคำสั่งซื้อ อุ้งเท้าจะอยู่ที่ orders แปลว่าลูกค้าหนึ่งคนสั่งซื้อได้หลายครั้ง

ตัวอย่างสั้น ๆ จะเห็นภาพขึ้นทันที:

CREATE TABLE customers (
  customer_id INTEGER PRIMARY KEY,
  name TEXT NOT NULL
);

CREATE TABLE orders (
  order_id INTEGER PRIMARY KEY,
  customer_id INTEGER,
  total NUMERIC,
  FOREIGN KEY (customer_id) REFERENCES customers (customer_id)
);

พอวางลงไป จะได้สองกล่องเชื่อมกันด้วยเส้นเดียว — customers เป็นฝั่ง "หนึ่ง" orders เป็นฝั่ง "หลาย" — โดย customer_id ถูกทำเครื่องหมายเป็น primary key ของ customers และเป็น foreign key ใน orders

สิ่งที่ไม่ถูก parse เครื่องมือเน้นโครงสร้าง ไม่ใช่รายละเอียดทุกอย่างของ DDL index, CHECK และ UNIQUE constraint ที่ไม่ได้นิยาม key, trigger, view และ storage option ไม่ถูกวาดขึ้น ให้ถือ diagram เป็นแผนที่ของ table กับความสัมพันธ์ ส่วน DDL เต็มยังคงเป็น source of truth ของทุกอย่างที่เหลือ และความสัมพันธ์ที่นิยามไว้แค่ใน application code หรือ ORM model จะไม่ปรากฏ เว้นแต่มันมีอยู่จริงในรูป clause ของ FOREIGN KEY ใน SQL ที่คุณวางลงไป

กรณีใช้งานจริง

1. Onboarding เข้าสู่ schema ที่ไม่คุ้นเคย

เพิ่งย้ายเข้าโปรเจกต์ legacy เหรอ? export คำสั่ง CREATE TABLE ออกมาวาง แล้วคุณจะมีแผนที่ของ domain ภายในไม่กี่นาที สมาชิกใหม่จะเข้าใจ core entity ได้เร็วกว่าไล่แกะ migration ทีละไฟล์

2. Design review

วาง schema ที่เสนอไว้ก่อนประชุม เพื่อให้ reviewer เห็น cardinality ตาแรกและตั้งคำถามที่คมขึ้น: order_items ควรอ้างอิง orders หรือไม่? การ denormalize แบบนี้ตั้งใจหรือเผลอ? ภาพตรงหน้าทำให้การคุยจับต้องได้กว่าคำอธิบายเปล่า ๆ

3. เอกสารที่ตามโลกจริง

เก็บ diagram ที่ได้ไว้ใน wiki ของทีมคู่กับ DDL เมื่อ schema เปลี่ยน ให้วางคำสั่งชุดใหม่แล้วรีเฟรชภาพ เอกสารจะได้เดินตามความจริงแทนที่จะค่อย ๆ คลาดเคลื่อน

4. สอนเรื่อง normalization

ลองโชว์ design แบบ denormalize ก่อน คุยเรื่อง normal form แล้ววาง DDL ฉบับแก้แล้วเพื่อเทียบขอบเขต entity ที่สะอาดขึ้น ความต่างที่เห็นด้วยตาทำให้เรื่องนามธรรมกลายเป็นรูปธรรมทันที

แนวปฏิบัติที่ดี

• ตั้งชื่อ foreign key ให้ชัดเจน: customer_id ที่อ้างอิง customers อธิบายตัวเองได้ ส่วน ref_id ที่อ้างอิง customers คือปริศนาทั้งในโค้ดและใน diagram
• วาง DDL ให้ครบ: ใส่ทุก table ที่เกี่ยวข้องกับความสัมพันธ์ที่สนใจ — diagram ที่เห็นครึ่งเดียวของ schema ก็ซ่อน join path ครึ่งเดียว
• อัปเดต diagram หลัง schema เปลี่ยน: วางผลลัพธ์ migration ล่าสุดใหม่ทุกครั้งที่ table เปลี่ยน เพื่อให้ภาพไม่เคยโกหก
• มี source of truth เดียว: สร้าง DDL จาก migration แทนการดูแลสำเนาที่แก้มือ แล้วเอาผลลัพธ์นั้นมา visualize
• ใช้ naming convention ที่สม่ำเสมอ: เอกพจน์หรือพหูพจน์ เลือกสักอย่าง ชื่อที่ consistent ทำให้ทั้ง diagram และ join อ่านง่ายขึ้น
• แคปหน้าจอไว้ใช้งาน: แนบ diagram ที่ได้ลงใน pull request และ design doc เพื่อให้ reviewer เห็นโครงสร้างทันทีโดยไม่ต้องรันอะไร

เห็น Schema ของคุณในไม่กี่วินาที

เลิกจินตนาการ schema ในหัวคนเดียว เปิด SQL Schema Visualizer วางคำสั่ง CREATE TABLE แล้วดู table, key และความสัมพันธ์จัดตัวเป็น ER diagram ที่อ่านง่าย — ฟรี ทันที และอยู่ในเบราว์เซอร์ของคุณล้วน ๆ

เครื่องมือที่เกี่ยวข้องที่คุณอาจชอบ:

• SQLite Viewer — เปิดไฟล์ .db และเรียกดู table กับข้อมูลโดยไม่ต้องติดตั้งอะไร
• JSON Formatter — จัดรูป ตรวจสอบ และบีบอัด JSON สำหรับ payload และ config
• SQL Formatter — จัดระเบียบ query และ DDL ให้สะอาดก่อนวางหรือ commit

ขอให้สนุกกับการออกแบบ schema!

คำถามที่พบบ่อย

ถ: SQL ของฉันถูกอัปโหลดไปที่ server หรือไม่?

ตอบ: ไม่ การ parse และแสดงผลเกิดขึ้นในเบราว์เซอร์ของคุณทั้งหมดด้วย JavaScript ฝั่ง client schema จึงไม่เคยออกจากเครื่องของคุณ

ถ: รองรับ SQL dialect แบบไหนบ้าง?

ตอบ: ไวยากรณ์ CREATE TABLE มาตรฐานของ MySQL, PostgreSQL, SQLite และ SQL Server ใช้ได้ ส่วน clause เฉพาะของแต่ละเจ้าจะถูกเมินอย่างสง่างามโดยไม่ทำให้ parse พัง

ถ: เครื่องมือแสดง index และ unique constraint ด้วยไหม?

ตอบ: ไม่ diagram เน้น table, column, primary key และความสัมพันธ์ของ foreign key ส่วนที่เหลือให้ DDL เต็มยังคงเป็น source of truth

ถ: รองรับ table กี่ตัว?

ตอบ: ระดับสิบกว่าถึงร้อยกว่า table แสดงผลได้สบาย dump ที่ใหญ่มากจะเริ่มแน่นเกินไป ลอง visualize ทีละ module แทน

ถ: ใช้ความสัมพันธ์ที่นิยามไว้ใน ORM แทน SQL ได้ไหม?

ตอบ: ไม่ได้โดยตรง เครื่องมืออ่าน DDL ความสัมพันธ์จึงต้องมีอยู่จริงในรูป clause ของ FOREIGN KEY ใน SQL ที่คุณวางลงไปจึงจะปรากฏบน diagram