ChartDB – เครื่องมือออกแบบฐานข้อมูลโอเพนซอร์สฟรี

 (chartdb.io)
2 คะแนน โดย GN⁺ 2024-08-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ChartDB เป็น เครื่องมือแก้ไขไดอะแกรม DB สำหรับแสดงภาพสคีมาฐานข้อมูลอย่างรวดเร็วและจัดการในรูปแบบ ER diagram โดยมุ่งเน้นการทำงานร่วมกันในทีมและงานย้ายสคีมา
  • Cloud ทำงานบนเบราว์เซอร์ และชูจุดเด่นว่าสามารถได้ไดอะแกรมภายใน 15 วินาทีโดย ไม่ต้องเข้าถึงฐานข้อมูล
  • Self-Hosted ให้บริการในรูปแบบโอเพนซอร์สฟรี เหมาะกับความต้องการด้าน ความปลอดภัยและการปรับแต่ง ที่ต้องควบคุมข้อมูลและการตั้งค่าด้วยตนเอง
  • รองรับการนำเข้าสคีมาด้วยคิวรีเดียว, การสร้าง AI ER diagram, การส่งออก SQL DDL, การซิงก์อัตโนมัติ, การทำงานร่วมกันแบบเรียลไทม์, เอกสารแบบฝัง และการติดตามการเปลี่ยนแปลง
  • สามารถใช้กับการออกแบบ relational DBMS และคลาวด์ดาต้าแวร์เฮาส์หลายประเภท ตั้งแต่ PostgreSQL, MySQL, SQL Server, SQLite, MariaDB, ClickHouse, CockroachDB, Oracle, Snowflake ไปจนถึง BigQuery

ไดอะแกรมสคีมา DB ที่จัดการได้บนเบราว์เซอร์

  • ChartDB เป็นเครื่องมือสำหรับแสดงภาพสคีมาฐานข้อมูลทันทีและสร้าง ER diagram
  • แนะนำว่าเป็น เครื่องมือแก้ไขไดอะแกรม DB สำหรับใช้ในการทำงานร่วมกันในทีมและการย้ายสคีมา
  • ปุ่มเริ่มต้นเชื่อมต่อไปยังแอป ChartDB พร้อมข้อความเริ่มใช้งานฟรีและไม่ต้องใช้บัตรเครดิต
  • บน GitHub แสดงว่า ChartDB มี +19K stars

ตัวเลือก Cloud และ Self-Hosted

  • ChartDB Cloud เป็นวิธีแสดงภาพฐานข้อมูลบนเบราว์เซอร์
    • แนะนำว่าเหมาะกับความสะดวกในการใช้งานและการเข้าถึงของทีม
    • ระบุว่าสามารถใช้งานได้โดยไม่ต้องเข้าถึงฐานข้อมูล
    • ชูจุดเด่นว่าสามารถได้ไดอะแกรมภายใน 15 วินาที
  • Self-Hosted เป็นเครื่องมือออกแบบฐานข้อมูลโอเพนซอร์สฟรี
    • สามารถควบคุมข้อมูลและการตั้งค่าได้อย่างสมบูรณ์
    • เป็นตัวเลือกที่เหมาะกับสภาพแวดล้อมที่ต้องการความปลอดภัยและการปรับแต่ง
  • ChartDB อธิบายว่าสามารถแสดงภาพ DB ได้ด้วย “คิวรีเดียว”

เวิร์กโฟลว์ Import → Edit → Export

  • Instant Import

    • มีคิวรีเดียวสำหรับนำเข้าสคีมาทั้งหมดของแต่ละฐานข้อมูล
    • ระบุว่าสามารถนำเข้าสคีมาได้ภายใน 15 วินาที

  • Relational DBMS

    • กล่าวถึง MySQL, MariaDB, PostgreSQL, Microsoft SQL Server, SQLite ว่าเป็น DBMS ยอดนิยมและแสดงเป็นรายการที่รองรับ

  • Export SQL

    • สามารถดาวน์โหลดไดอะแกรมเป็นสคริปต์ SQL DDL เพื่อนำไปรันกับฐานข้อมูลได้
    • สามารถส่งออกเป็นรูปภาพสำหรับใส่ในเอกสารได้ด้วย

  • Examples

    • มีตัวอย่างที่ออกแบบไว้ล่วงหน้าเพื่อช่วยตั้งค่าอย่างรวดเร็วและใช้เป็นข้อมูลอ้างอิงในการออกแบบ
    • รายการนี้แสดงเป็น WIP

  • Advanced Query Editor

    • มีฟังก์ชัน undo, redo, copy, paste และ duplicate
    • สามารถเพิ่มตาราง, subject area และโน้ตได้

  • Beautiful Shares

    • สามารถสร้างตัวอย่างภาพของไดอะแกรมฐานข้อมูลเพื่อแชร์กับผู้อื่นได้

ฟีเจอร์สร้าง แชร์ และซิงก์ไดอะแกรม

  • ChartDB - AI Agent
    • แปลงไอเดียฐานข้อมูลที่ใส่ในพรอมป์ต์ให้เป็น ER diagram ที่ปรับแต่งแล้วและแก้ไขได้
  • Instant Import
    • ฟีเจอร์สำหรับนำเข้าสคีมา DB ทั้งหมดด้วยคิวรีเดียว
  • Export SQL
    • สร้างสคริปต์ DDL ในภาษา SQL dialect ที่ต้องการ
  • Sync Database
    • ซิงก์ฐานข้อมูลจริงกับไดอะแกรมโดยอัตโนมัติ
  • Real time collaboration
    • เชิญสมาชิกทีมให้ดูและแก้ไขไดอะแกรมแบบเรียลไทม์ได้
  • Amazing Docs
    • สร้างไดอะแกรมที่ฝังได้และเอกสารแบบขยายได้ที่ปรับแต่งได้
  • Keep on track
    • ติดตาม diff และประวัติเวอร์ชันของการเปลี่ยนแปลงสคีมา

ฐานข้อมูลที่รองรับ

  • ChartDB ระบุว่ารองรับการออกแบบสำหรับฐานข้อมูลและคลาวด์ดาต้าแวร์เฮาส์
  • รายการที่แสดงว่ารองรับมีดังนี้
    • PostgreSQL
    • MySQL
    • SQL Server
    • SQLite
    • MariaDB
    • ClickHouse
    • CockroachDB
    • Oracle
    • Snowflake
    • BigQuery

คำถามด้านการใช้งานที่พบได้ใน FAQ

  • มีคำถามว่า ChartDB จะแก้ไขฐานข้อมูลหรือไม่
  • มีรายการคำถามว่าสามารถฝัง live ERD ใน Notion, Miro, Confluence ได้หรือไม่
  • มีรายการที่ตรวจสอบว่าสามารถทดลองใช้แผน ChartDB Cloud ได้ฟรีหรือไม่
  • FAQ ยังมีรายการเกี่ยวกับวิธีขอรับการสนับสนุน, วิธีซิงก์ไดอะแกรมกับฐานข้อมูล และมีใบแจ้งหนี้กับการชำระเงินสำหรับธุรกิจหรือไม่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-29
ความคิดเห็นจาก Hacker News

  • เคยเห็นทีมโปรเจกต์เริ่มพัฒนาแอปใหม่โดยไม่มีไดอะแกรมพื้นฐานสักอันที่อธิบายแง่มุมใด ๆ ของโซลูชัน รวมถึง โมเดลข้อมูล ด้วย อยู่บ่อยครั้ง
    ไม่แน่ใจว่าต้องทำอย่างไรถึงจะทำให้ ER diagram แบบเรียบง่ายกลายเป็นมาตรฐานของเอกสารโครงการได้ เครื่องมือมีเยอะ แต่แทบไม่ถูกใช้จริงในภาคสนาม
    ถ้าอยากให้คนใช้ อาจต้องให้ Microsoft ใส่มันเป็นฟีเจอร์ใน Excel หรือ PowerPoint ก็ได้ ไดอะแกรมไม่จำเป็นต้องสมบูรณ์แบบ แค่สื่อโครงสร้างหลักและความสัมพันธ์ที่สำคัญตามบริบทก็พอ ถ้าจำเป็นก็ทำไดอะแกรมเล็ก ๆ หลายอันสำหรับฐานข้อมูลเดียวกันเพื่อบันทึก requirement และการออกแบบได้

    • นึกเหตุผลออกอยู่หลายข้อ คนที่มีพื้นฐาน MIS (Management Information Systems) มักสนใจฐานข้อมูลมากกว่าคนสายวิทยาการคอมพิวเตอร์ (CS) และมักเริ่มจาก ERD ก่อนค่อยไปโค้ดทีหลัง ส่วนฝั่ง CS มักอยากเริ่มเขียนโค้ดก่อน
      อีกอย่าง UML แทบจะเป็นหายนะ มันกลายเป็นเหมือนตัวแทนของภาษาสำหรับไดอะแกรมตั้งแต่ยุค 90 แต่กลับไม่มีองค์ประกอบสำหรับฐานข้อมูล และต้องฝืนใช้ class diagram ให้คล้าย ERD แทน UML ไม่ใช่โค้ด และการเขียนโค้ดด้วย UML ก็ยากมากหรือแทบเป็นไปไม่ได้ ERD กลับไปกลับมาระหว่างโค้ดกับไดอะแกรมได้ง่ายกว่ามาก แต่การเขียนโค้ดประเภทอื่นไม่เป็นแบบนั้น
      ผมคิดว่าการผงาดขึ้นและความล้มเหลวของ UML มีส่วนมากที่ทำให้นักพัฒนาเลิกวาดไดอะแกรม อีกทั้งสำหรับนักพัฒนาส่วนใหญ่ แค่มี เครื่องมือสำรวจโค้ด ที่แสดงโครงสร้างโค้ดเป็นต้นไม้ในแถบด้านซ้ายของตัวแก้ไขก็เพียงพอแล้ว
    • เห็นด้วยนะ เพราะเวลาทำความเข้าใจระบบ ผมก็มองจากข้อมูลก่อน แต่ก็รู้สึกว่าเราไม่ใช่คนส่วนใหญ่ อย่างน้อยใน ecosystem ของ Microsoft การเติบโตของแนวทาง code-first ก็ไม่ใช่สิ่งที่ผมชอบเป็นการส่วนตัว

  • เมื่อก่อนผมค่อนข้างมอง ERD ในแง่บวก และมักใช้มันเป็น งาน onboarding แม้กับฐานข้อมูลที่มีตารางเกิน 100 ตาราง แต่เดี๋ยวนี้ ERD แบบครอบคลุมทั้งระบบเริ่มพบได้น้อยลง และผมคิดว่าก็ไม่เป็นไร
    ต้นทุนการดูแลรักษาสูง ทำให้คุณค่าของมันอยู่ได้ไม่นาน ถ้ามี ERD ที่ขัดเกลาดีก็เยี่ยม แต่ไม่ถึงกับจำเป็น
    เวลาสร้าง ERD จากโค้ด เครื่องมืออย่าง dbdiagram.io หรือ eraser.io ถูกใช้กันมาก ส่วน ERWin ถือเป็นเจ้าดั้งเดิมของไดอะแกรม UML/ERD แต่ราคาแพง

    • การทำสิ่งนี้ด้วยมือแทบจะเรียกว่าเป็นความผิดพลาดได้ อย่างที่บอกไป การบำรุงรักษายากมาก ผมคิดว่าฐานข้อมูลทุกตัวควร สร้างไดอะแกรมอัตโนมัติ ได้ หรืออย่างน้อยก็ควรมีเครื่องมือสำหรับสร้างอัตโนมัติ

  • สงสัยว่าทำไมคนถึงใช้เครื่องมือแบบนี้ ใช้เพื่อคุยกับผู้จัดการหรือเปล่า?
    ถามจริงจังนะ ผมเองอาจควรใช้เหมือนกัน แต่ยังไม่เข้าใจว่าทำไมมันถึงจำเป็น

    • ควรใช้เมื่อความซับซ้อนถึงระดับที่มันเริ่มมีความหมาย ถ้าโปรเจกต์โตจนคุณไม่สามารถ หรือไม่อยาก เก็บ โมเดลฐานข้อมูล ทั้งหมดไว้ในหัว ก็ถึงเวลาต้องใช้
      มันยังจำเป็นเมื่อมีหลายโมเดลในหลายระบบ เวลาทำงานกับคนอื่นแล้วอยากสื่อสารโมเดลฐานข้อมูลให้ง่ายขึ้น เวลาต้องอธิบายต่อสาธารณะ หรือเมื่อต้องการวางแผนโมเดลล่วงหน้า
      และคำว่า “ควรใช้” ในที่นี้หมายถึงไดอะแกรมปลายทาง ไม่ได้หมายถึงเครื่องมือนี้โดยเฉพาะเสมอไป
    • ผมเคยใช้เครื่องมือพวกนี้เพื่อจัดระเบียบแบบที่อยู่ในหัว ส่วนตัวชอบ DBML เพราะเอาเข้า source control ได้ง่าย และมีปลั๊กอินสำหรับ editor ด้วย
      https://dbml.dbdiagram.io/home/
    • เพราะ “ภาพหนึ่งภาพดีกว่าคำพูดพันคำ”
      ถ้าคุณเคยรับช่วงโปรเจกต์ที่มีตาราง 80 ตารางโดยไม่มีเอกสารอะไรเลย หรืออย่างมากก็มีแค่เอกสาร 50 หน้าที่ใส่ schema dump ของฐานข้อมูลไว้ คุณจะเข้าใจทันที
      คุณสามารถวาดตารางหลักและความสัมพันธ์ลงใน ERD (Entity-Relationship Diagram) แผ่นเดียว แล้วเข้าใจมันได้ในไม่กี่นาที แทนที่จะใช้เวลาหลายชั่วโมงหรือหลายวันเหมือนตอนอ่าน schema dump
      ในขั้นออกแบบ schema คุณอาจใช้ตัวแก้ไข ERD หลายแบบ หรือเครื่องมือทำไดอะแกรมแบบข้อความอย่าง PlantUML, MermaidJS, DBML และยังเก็บต้นฉบับของไดอะแกรมไว้ใน source control ได้ด้วย
      นอกจากนี้ยังสามารถให้ CI สร้าง ERD แบบละเอียดของ schema ฐานข้อมูลปัจจุบัน แล้วตรวจทานเป็นระยะ เพื่อเช็กว่ายังตรงกับแบบเดิมไหม และเรายังเข้าใจ schema ปัจจุบันถูกต้องอยู่หรือไม่
    • มันทำให้สื่อสารกับฝั่งธุรกิจ และอธิบาย ข้อจำกัดทางเทคนิค หรือความต้องการด้านข้อมูลได้ง่ายขึ้นมาก ยังช่วยเวลาออกแบบร่วมกันในโปรเจกต์ที่ซับซ้อน และทำให้เห็นชัดว่าเรายังตอบโจทย์ requirement ด้านข้อมูลตรงไหนไม่ได้บ้าง
    • คล้ายกับเอกสารประกอบอย่าง JavaDoc ตรงที่มันให้ มุมมองที่กระชับกว่า ว่าอะไรทำงานอย่างไร
      ผมเกลียดทัศนคติแบบ “โค้ดมันอธิบายตัวเองได้อยู่แล้ว!” มาก

  • เห็นบริการลักษณะนี้หลายตัว แต่สิ่งที่ผมหาคือเครื่องมือที่เรียกใช้ตรง ๆ หรือ ควบคุมด้วยสคริปต์ ได้
    use case ของผมคือสร้างไดอะแกรมฐานข้อมูลที่ค่อนข้างเรียบง่ายจากคำอธิบายโมเดลที่มีอยู่เป็นส่วนหนึ่งของโปรเซสอื่น ในโครงสร้างหน่วยความจำผมมีชื่อตาราง ชื่อคอลัมน์ และความสัมพันธ์อยู่แล้ว และอยากวาดไดอะแกรมคล้าย ER
    ตอนนี้กำลังดูแนวทางที่สร้างไฟล์ puml จากข้อมูลของตัวเอง แล้วรัน PlantUML เพื่อสร้าง png หรือ svg
    เท่าที่หาเจอ ส่วนใหญ่เป็นเครื่องมือออกแบบฐานข้อมูลแบบครบชุดที่มี editor ของตัวเอง แต่ไม่มี API และเครื่องมืออย่างตัวนี้หรือ dbdiagram.io ก็มักเป็นออนไลน์เท่านั้น เลยไม่ตอบโจทย์ผม ถ้ามีคำแนะนำจะขอบคุณมาก

    • ไม่แน่ใจว่าเคยลอง SchemaSpy หรือยัง

  • ถ้ามีสิ่งนี้ตอนเริ่มโปรเจกต์เมื่อ 5 ปีก่อนคงดีมาก ตอนนั้นผมต้องออกแบบ schema ฐานข้อมูล สำหรับโปรเจกต์ full-stack ที่ใช้ Postgres และทำงานร่วมกับผู้เชี่ยวชาญด้านวิทยาศาสตร์
    การทบทวนไดอะแกรมร่วมกันช่วยได้มาก เพราะผู้เชี่ยวชาญคนนั้นสามารถชี้ปัญหาที่อาจเกิดขึ้นจาก requirement เฉพาะโดเมนในอนาคตได้
    ตอนนั้นเราประชุม one-on-one กันหลายครั้ง และผมจะจดสิ่งที่ต้องแก้ก่อนการประชุมครั้งถัดไปขณะดูไดอะแกรมไปด้วย
    ถ้ามีเครื่องมือแบบนี้ ผมน่าจะแก้ตรงนั้นได้เลยระหว่างประชุม และลดจำนวนรอบการทำซ้ำลงได้มาก แม้จะมีอย่าง pgAdmin อยู่แล้ว แต่มันไม่ได้ดูเป็นมิตรกับคนที่ไม่ใช่สายเทคนิค และเครื่องมือนี้น่าจะช่วยลดแรงเสียดทานได้

  • มันเจ๋งดี แต่ปัญหาหลักของเครื่องมือแบบนี้คือมันเป็น ทางเดียว และพยายามวางตัวเป็นแหล่งอ้างอิงกลาง ทั้งที่นี่คือรูปภาพ ไม่ใช่ฐานข้อมูล
    ผมเข้าใจว่าทำไมคนถึงใช้ แต่ผมไม่ต้องการเครื่องมือแบบนี้
    เพราะสุดท้ายทุกเครื่องมือก็มี “export เป็น SQL” และคาดหวังว่าทุกการเปลี่ยนแปลงในฐานข้อมูลจะต้องสะท้อนกลับมาที่ไดอะแกรม แต่ไดอะแกรมไม่ใช่ฐานข้อมูล ดังนั้นงานจึงกลายเป็นสองชุด

    • คำว่า “ไดอะแกรมไม่ใช่ฐานข้อมูล” ก็เหมือนกับ “แผนที่ไม่ใช่อาณาเขต”
      ไดอะแกรมคือ โมเดล และโมเดลนั้นมีอยู่เสมอ ไม่ว่าจะเขียนออกมาชัดเจนหรือมีอยู่แค่ในหัว
      โมเดลในหัวอาจผิดได้ แต่ไม่มีใครมองเห็น จึงไม่มีใครช่วยชี้ข้อผิดพลาดให้ได้ แม้แต่ตัวคุณเอง

  • DBeaver ก็รองรับ ERD ด้วย: https://dbeaver.com/docs/dbeaver/ER-Diagrams/
    มันเป็นแบบ interactive และแก้ไขได้ จะเรียกว่า “สวย” ก็คงยากหน่อย แต่ทั้งผลิตภัณฑ์เป็น FOSS และมีประโยชน์มากสำหรับงานฐานข้อมูล

    • ผมเจอปัญหาไม่น้อยกว่าจะทำให้ ERD ใน DBeaver ทำงานได้อย่างที่ต้องการ สำหรับคนแบบผมก็โอเค เพราะผมลองปรับไปเรื่อยจนกว่าจะใช้ได้
      แต่สำหรับบางคนที่เคยร่วมงานด้วย มันไม่เป็นแบบนั้น ปกติแล้วช่วงเวลาที่ต้องใช้สิ่งนี้ก็คือเวลาทำงานออกแบบร่วมกับคนที่ไม่ได้ชำนาญ SQL แต่มี ความรู้ด้านโดเมน และเอาสเปรดชีต Excel ขนาดเล็กเท่าฐานข้อมูลหนึ่งก้อนมาด้วย

  • เป็นหน้า landing page แบบ static แต่ไม่เข้าใจว่าทำไมถึงมีอาการ กระตุกตอนเลื่อน หนักขนาดนี้