สารบัญ
Series: Database 101 — เข้าใจห้องสมุดของเมืองดิจิทัล (ภาษาคน)
Part 0 — WHY: ทำไมต้องมีห้องสมุด
Part 1 — ประวัติ: 4 ยุคของ Database
- EP.02 — ยุค 1960s-70s: Hierarchical → Relational Revolution
- EP.03 — ยุค 1980s-90s: ACID + Enterprise Backbone ← คุณอยู่ตรงนี้
- EP.04 — ยุค 2000s-2010s: NoSQL Movement + Big Data
- EP.05 — ยุค 2020s: Cloud-Native + Serverless Database (เร็วๆ นี้)
Part 2 — How: ภายใน Database ทำงานยังไง
- EP.06 — Schema, Normalization, Keys (เร็วๆ นี้)
- EP.07 — Index + Query Optimization (เร็วๆ นี้)
- EP.08 — Transaction + Concurrency Control (เร็วๆ นี้)
Part 3 — เลือก Storage ตามขนาด
- EP.09 — มุมเว็บส่วนตัว: Database-less Architecture (เร็วๆ นี้)
- EP.10 — มุม Personal Data: SQLite + Local-first (เร็วๆ นี้)
- EP.11 — มุม Startup: Serverless DB Stack (เร็วๆ นี้)
- EP.12 — มุม Enterprise: Polyglot Persistence (เร็วๆ นี้)
Part 4 — Operations
- EP.13 — DBA Role + Privileged Access (เร็วๆ นี้)
- EP.14 — Database Security + Encryption (เร็วๆ นี้)
Part 5 — Future
- EP.15 — Vector Database + AI Era (เร็วๆ นี้)
- EP.16 — Wrap: Decision Tree + 5 Trends (เร็วๆ นี้)
ครับ EP.02 เราจบที่ภาพของ Edgar Codd ที่จุดประกาย relational model ขึ้นมาในปี 1970 แล้ว IBM กับ Oracle ก็แข่งกันเอาแนวคิดนั้นออกขายจริงปลายยุค 70s relational ชนะการประกวดทางทฤษฎีไปเรียบร้อย แต่ “ชนะทฤษฎี” กับ “ชนะตลาด” มันคนละเรื่องกัน
ปี 1980 ถ้าคุณเดินไปคุยกับผู้จัดการธนาคารแล้วบอกเขาว่า “เอา ledger ที่จดในสมุดลงคอมพิวเตอร์ดีกว่า” เขาน่าจะมองคุณเหมือนคนบ้าเลยครับ ไม่ใช่เพราะเขาไม่เข้าใจคอมพิวเตอร์ เขาเข้าใจดีพอที่จะกลัวมันต่างหาก คำถามของเขาคือ “ถ้าระบบดับกลางการโอนเงิน เงินจะหายมั้ย?” และในปี 1980 คำตอบที่ honest ที่สุดคือ “อาจจะหาย”
EP.03 คือเรื่องของทศวรรษที่วงการ database หา “คำตอบที่ honest แต่ไม่ใช่ ‘อาจจะหาย’” เจอ คำตอบนั้นย่อเป็น 4 ตัวอักษรที่เปลี่ยนวงการธนาคารทั้งโลก ACID พอ ACID มา Oracle, IBM, Microsoft, Sybase ก็แข่งกันยึดตลาด enterprise ระบบ ERP เริ่มขึ้นทุกบริษัทใหญ่ในโลก และตำแหน่งงานใหม่ชื่อ DBA ก็เกิดมาเป็น “คนถือกุญแจทุกดอก” ของบริษัท
มาเริ่มกันที่ฉากที่ผู้จัดการธนาคารกลัวที่สุดก่อน
ฉากเปิด: ATM โอนเงินตอนไฟดับ
สมมติคืนวันศุกร์ คุณยืนหน้า ATM กดโอนเงิน 1,000 บาทจากบัญชีตัวเองไปยังบัญชีของน้อง กดเสร็จ หน้าจอขึ้น “กำลังดำเนินการ…” แล้ว บึ่ม ไฟดับทั้งสาขา
อีก 30 วินาทีต่อมาไฟกลับมา คุณดึงสมุดบัญชี check ทันที คำถามคือ ตอนนี้ในระบบเกิดอะไรขึ้นได้บ้าง?
มี 4 สถานการณ์ที่เป็นไปได้
- ดีที่สุด ระบบยังไม่ทันทำอะไรเลย บัญชีคุณยัง 50,000 บาทเท่าเดิม บัญชีน้องไม่เพิ่ม คุณกดใหม่ได้
- โอเคก็ได้ ระบบทำเสร็จทั้งสองขั้นตอนพอดีก่อนไฟดับ บัญชีคุณ -1,000 บาท บัญชีน้อง +1,000 บาท ครบ
- ฝันร้ายแบบที่ 1 ระบบหักจากบัญชีคุณ 1,000 บาทไปแล้ว แต่ไฟดับก่อนจะเพิ่มในบัญชีน้อง เงิน 1,000 บาทหายไปจากระบบ
- ฝันร้ายแบบที่ 2 ระบบเพิ่มในบัญชีน้อง 1,000 บาทไปแล้ว แต่ไฟดับก่อนจะหักจากบัญชีคุณ เงิน 1,000 บาทเกิดมาจากอากาศ ธนาคารเสียเงินฟรีๆ
สถานการณ์ที่ 1 กับ 2 ธนาคารยอมรับได้ สถานการณ์ที่ 3 กับ 4 ยอมรับไม่ได้เด็ดขาด เพราะถ้าเกิดบ่อยเข้า ระบบจะหมดความน่าเชื่อถือทันที ลองนึกถึงข่าวว่า “ธนาคาร X ทำเงินหายเดือนละ 50 ล้านบาทเพราะระบบดับ” สิ้นปีไม่มีลูกค้าเหลือเลย
นี่แหละครับปัญหาที่ทำให้ผู้จัดการธนาคารยุค 70s-80s นอนไม่หลับ และเป็นเหตุผลที่ ACID ต้องเกิดมา ก่อนที่ใครจะกล้ายอมให้คอมพิวเตอร์ถือเงินจริงๆ
ยุคก่อน ACID — ทำไมธนาคารกลัวคอมพิวเตอร์
ย้อนไปต้นยุค 70s ธนาคารใหญ่หลายแห่งทั่วโลกยังลงรายการเงินด้วย paper ledger (สมุดบัญชีแบบเล่ม) พนักงานนั่งเขียนทุกรายการลงสมุดด้วยมือ ตอนเช้าเปิดยอด ตอนเย็นปิดยอด ทุกวัน ฟังดู primitive แต่ระบบนี้มีจุดแข็งที่คอมพิวเตอร์ยุคนั้นยังไม่มี
จุดแข็งของกระดาษ: คนเห็นทั้งกระบวนการ ถ้าจดผิดมีรอยขีดฆ่าให้เห็น ถ้าหายไปสองหน้าเห็นทันที ตอนปิดยอดเย็นถ้าไม่ตรง มีคนนั่งไล่ทีละบรรทัดจนเจอ ทุกขั้นตอนมีร่องรอยทางกายภาพที่ตามดูได้
ส่วน คอมพิวเตอร์ยุค 70s มีปัญหาตรงข้ามกัน ทุกอย่างซ่อนอยู่หลังจอ ถ้าระบบดับกลาง transaction ไม่มีใครรู้ว่ามันทำขั้นตอนไหนไปแล้วบ้าง ถ้า hard disk เสีย ข้อมูลหายเป็นพันรายการในเสี้ยววินาที ถ้า bug ในโปรแกรมหักเงินผิด รู้ตอนเช้าวันรุ่งขึ้นที่ลูกค้าโทรเข้ามาด่า
ธนาคารหลายแห่งเลยใช้ระบบ hybrid กลางวันรับฝาก-ถอนปกติ ตอนเย็นพนักงานเอารายการทั้งหมดมา เทียบมือ กับ paper ledger ก่อนปิดวัน ใช้คนเป็นสิบคนต่อสาขา ทำงาน 2-3 ชั่วโมงทุกเย็น แค่เพื่อยืนยันว่า “คอมพิวเตอร์ไม่ได้จดผิด”
ค่าใช้จ่ายสูง? สูง แต่ถูกกว่าค่าความเสียหายถ้าระบบเพี้ยน
นี่แหละ context ที่ทำให้ ACID เกิดมา มันไม่ใช่แค่ feature ของ database มันคือ “ความเชื่อมั่น” ที่ทำให้ธนาคารกล้าเลิกจ้างคนเทียบมือตอนเย็น กล้ายอมให้คอมพิวเตอร์ถือเงิน 100% โดยไม่มี backup paper trail กว่าจะถึงจุดนั้นได้ วงการต้องการ guarantee 4 ข้อ
ACID 4 ตัว — สอน analogy ก่อน, ตัวอักษรทีหลัง
ผมจะไม่เริ่มด้วย “A คืออะไร C คืออะไร” ครับ จะเริ่มด้วยสถานการณ์โอนเงิน ATM ที่เพิ่งเล่าไป แล้วค่อยๆ ใส่ตัวอักษรเข้าไป
A — Atomicity (ทำครบหรือไม่ทำเลย)
กลับมาที่สถานการณ์โอนเงิน Atomicity คือกฎข้อแรกที่บอกว่า การโอนเงิน 1,000 บาทจาก A ไป B ไม่ใช่ “2 ขั้นตอน” มันคือ “1 ก้อนที่แตกไม่ได้” หักจาก A 1,000 + เพิ่มที่ B 1,000 = package เดียวกัน ถ้าทำสำเร็จก็สำเร็จทั้งคู่ ถ้าล้มเหลวก็ rollback ทั้งคู่กลับไปเหมือนไม่เคยทำ
Analogy: สั่ง pizza online แล้วเลือก “ส่งครบทั้งกล่อง” ถ้ารถส่งคว่ำกลางทาง ร้านส่งใหม่ทั้งกล่อง หรือคืนเงินเต็มจำนวน ไม่มี “ส่งให้ครึ่งกล่องแล้วเก็บเงินครึ่งราคา” มัน all-or-nothing
วิธีที่ database ทำได้แบบนั้น มันเก็บ “intent” (ความตั้งใจจะทำ) ไว้ก่อนใน log แยกต่างหาก ทำขั้นตอนทั้งหมดในพื้นที่ชั่วคราว พอครบค่อยกด commit ที่บอกว่า “เอาจริงแล้วนะ” ถ้ามีอะไรผิดพลาดระหว่างทาง ก็กด rollback ที่ลบทุกอย่างทิ้ง เหมือนไม่เคยเริ่ม
ในภาษาวงการเรียก package นี้ว่า transaction และ transaction หนึ่ง = atomic หนึ่งหน่วย เป็นคำที่จะเจอบ่อยที่สุดในเรื่อง database จำคำเดียวพอ
C — Consistency (หลังเสร็จ ข้อมูลยังตามกฎ)
Consistency คือกฎที่บอกว่า ก่อนและหลัง transaction ข้อมูลในระบบต้องยังตรงตามกฎที่กำหนดไว้ ในเคสโอนเงิน กฎคือ “ผลรวมของเงินในระบบต้องเท่าเดิม” ถ้าก่อนโอน A มี 50,000 + B มี 10,000 = 60,000 รวม หลังโอน 1,000 บาท A เหลือ 49,000 + B มี 11,000 = 60,000 รวมเหมือนเดิม เงินไม่หาย ไม่ทบ
Analogy: ลองนึกถึงห้องที่มีกฎว่า “คนในห้องห้ามเกิน 50” ทุกครั้งที่มีคนเข้า/ออก กฎนี้ต้องไม่ถูกละเมิด ถ้ามี action ไหนที่จะทำให้เกิน action นั้นถูกปฏิเสธทันที
ในภาษา database กฎพวกนี้เรียกว่า constraint มีหลายแบบ
- Foreign Key บัญชีต้องมีเจ้าของจริง ห้ามสร้าง transaction ของบัญชีที่ไม่มีอยู่
- Unique Key เลขบัตรประชาชนต้องไม่ซ้ำ ห้าม insert ซ้ำ
- Check Constraint ยอดเงินต้องไม่ติดลบ ห้ามหักเงินเกินยอดที่มี
- Not Null ทุก transaction ต้องมีวันที่ ห้ามว่างเปล่า
ถ้า transaction ไหนพยายาม commit แล้วทำให้กฎข้อใดข้อหนึ่งพัง database ปฏิเสธทันที rollback ทุกอย่างกลับ นี่แหละเหตุผลที่ Atomicity กับ Consistency เป็นพี่น้องกัน ตัวหนึ่งทำให้ rollback ได้ อีกตัวบอกว่าเมื่อไหร่ต้อง rollback
I — Isolation (transaction ไม่รบกวนกัน)
Isolation คือกฎข้อที่ลึกที่สุดในชุด ACID มันแก้ปัญหาที่ว่า ถ้ามีหลาย transaction เกิดพร้อมกัน เขาจะมองเห็นข้อมูลกลางคันของกันและกันไหม?
ลองนึกถึงเคสนี้ครับ บัญชีบริษัทมี 100,000 บาท คน 100 คนพยายามถอนเงิน 5,000 บาทพร้อมกันในวินาทีเดียวกัน ถ้าระบบไม่มี isolation ทุกคนจะเห็นยอด “100,000 บาท” พร้อมกัน ทุกคนคิดว่า “พอถอน” แล้วระบบหักเงินซ้อนกัน 100 ครั้ง = บัญชีติดลบ 400,000 บาท อ้าว 555+
Analogy: ห้องน้ำสาธารณะ มีกฎว่า “1 คนต่อ 1 ห้อง” คนที่เข้าก่อนปิดล็อก คนถัดไปต้องรอข้างนอก พอคนแรกออก คนถัดไปเข้าได้ มี คิว จัดการ ไม่มีใครเข้าไปทับซ้อน
ในภาษา database กลไกที่ทำให้เกิดคิวแบบนั้นเรียกว่า lock ตอน transaction หนึ่งกำลังอ่านหรือเขียนข้อมูลแถวไหน มันจะ lock แถวนั้นไว้ transaction อื่นที่จะแตะแถวเดียวกันต้องรอ พอคนแรกเสร็จก็ปลด lock คนถัดไปเข้าได้
ในชีวิตจริง isolation มี 4 ระดับ ที่ trade-off ระหว่าง “ปลอดภัยมาก แต่ช้า” กับ “เร็วมาก แต่อาจจะเห็นข้อมูลกลางคันของคนอื่น” ระดับพวกนี้ชื่อ Read Uncommitted, Read Committed, Repeatable Read, Serializable แต่ละอันมีรายละเอียดเยอะ (เรื่องนี้จะเจาะใน EP.08 — Transaction + Concurrency Control ตอนนี้รู้แค่ว่า “มีกลไกล็อกที่ทำให้หลาย transaction ไม่ทับซ้อนกัน” ก็พอ)
D — Durability (commit แล้ว ไฟดับก็ยังอยู่)
Durability คือกฎข้อสุดท้ายที่กลับมาตอบฉากเปิด ถ้า transaction commit สำเร็จไปแล้ว ต่อให้ไฟดับ server ระเบิด hard disk เสีย ข้อมูลที่ commit ไปแล้วต้อง ไม่หาย
Analogy: คุณเซ็นสัญญากับธนาคาร หลังเซ็นเสร็จ สัญญาถูก notarize (ผ่านการรับรอง) ทำสำเนา 3 ชุด เก็บในตู้เซฟกันไฟที่ 3 สาขาคนละที่ ต่อให้สำนักงานใหญ่ไฟไหม้ ยังมีสำเนาอีก 2 ที่ที่ตามเอามาได้
วิธีที่ database ทำให้ Durability เกิดขึ้น คือกลไกชื่อ WAL (Write-Ahead Log) ก่อนที่ transaction จะแก้ข้อมูลจริงในตาราง มันเขียน “log บอกว่ากำลังจะทำอะไร” ลง disk ก่อน log นี้เขียนเรียงลำดับ ลบไม่ได้ copy ไปได้หลายที่ พอ commit สำเร็จ log ก็บอกว่า “transaction นี้เสร็จแล้ว”
ถ้าระบบ crash ระหว่างทาง ตอน restart database จะเปิด log ขึ้นมาดูว่า transaction ไหนเริ่มแล้วยังไม่ commit? rollback transaction ไหน commit แล้วแต่ยังไม่ทันเขียนลงตารางจริง? redo เขียนซ้ำให้ครบ ผลคือตอน boot กลับมา ข้อมูลจะอยู่ในสถานะที่ “ทุก committed transaction อยู่ครบ ทุก uncommitted transaction หายไปทั้งก้อน”
นี่แหละเหตุผลที่ ATM ตัวจริงในปี 2026 ถ้าไฟดับกลางคุณกดโอน ตอนไฟกลับมา เงินจะอยู่ครบทุกบาท ไม่ใช่เพราะ ATM โชคดี แต่เพราะ database ใต้ ATM ผ่านการออกแบบมาให้รับมือกับเหตุการณ์นี้ตั้งแต่ 40 ปีที่แล้ว
สรุปสั้น ACID:
| ตัวอักษร | ชื่อเต็ม | คำเดียวจำ |
|---|---|---|
| A | Atomicity | ครบหรือไม่เลย |
| C | Consistency | กฎไม่ถูกละเมิด |
| I | Isolation | ไม่ทับซ้อน |
| D | Durability | commit แล้วไม่หาย |
ทีนี้พอ database มี ACID ครบ ปัญหาถัดมาของวงการคือ นักพัฒนาแต่ละคนพูดภาษาคนละแบบ และตรงนี้ที่ ANSI เข้ามาช่วย
SQL Standardization — ภาษากลางของวงการ
ปลายยุค 70s ต้นยุค 80s relational database มีหลายเจ้าออกมาขายพร้อมกัน IBM มี SQL/DS, Oracle มี Oracle V2, Ingres มีภาษา QUEL แต่ละเจ้ามี ภาษา query ของตัวเอง ที่คุยกับ database ไม่เหมือนกัน ถ้าบริษัทคุณเปลี่ยนจาก IBM เป็น Oracle โปรแกรมเดิมใช้ไม่ได้เลย ต้องเขียนใหม่ทั้งระบบ
นี่แหละสิ่งที่วงการเรียกว่า vendor lock-in การที่ลูกค้าเปลี่ยนเจ้าไม่ได้เพราะค่าย้ายแพงเกินไป Oracle ชอบมาก เพราะลูกค้าติดอยู่ แต่ลูกค้าเริ่มเหนื่อย มหาวิทยาลัยเริ่มบ่นว่า “สอนนักศึกษาเรียน database ของ vendor ไหนดี?”
ปี 1986 ANSI (American National Standards Institute) เข้ามาออก standard ของ SQL ฉบับแรก เรียกว่า SQL-86 กำหนดว่าไม่ว่าจะใช้ database ของเจ้าไหน คำสั่งพื้นฐาน (SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, JOIN ฯลฯ) ต้องเขียนเหมือนกัน ปี 1992 ออกเวอร์ชันที่ใหญ่กว่าเรียก SQL-92 ครอบคลุมกว่ามาก และยังเป็นรากฐานของ SQL ที่ใช้ทุกวันนี้
ผลกระทบใหญ่ของการ standardize:
- Training transferable เรียน SQL ครั้งเดียว ใช้ได้ทุกเจ้า นักศึกษาไม่ต้องเลือกข้างตั้งแต่ปี 1
- Vendor lock-in ลด บริษัทย้ายจาก vendor หนึ่งไปอีก vendor ทำได้ง่ายขึ้น (แม้ไม่ 100%)
- ตลาดโต เมื่อ skill SQL transferable นายจ้างรับ developer ได้ง่ายขึ้น ราคา developer ลด บริษัทกล้าใช้ database มากขึ้น
แต่… ในความเป็นจริง SQL ไม่ standard 100% ครับ แต่ละ vendor เพิ่ม extension ของตัวเองเข้าไป ที่ vendor อื่นไม่มี
- Oracle มี PL/SQL ภาษา programming ในตัวที่เขียน stored procedure ได้
- Microsoft SQL Server มี T-SQL (Transact-SQL) รุ่นของ Microsoft เอง
- PostgreSQL มี PL/pgSQL ของตัวเอง
- การ JOIN syntax ต่างกันเล็กน้อย การจัดการ date/time ต่างกันมาก การจัดการ NULL ต่างกันแบบหายนะ
นี่แหละเหตุผลที่ developer ที่ย้ายงานจาก Oracle มา SQL Server มักใช้เวลา 2-3 เดือนปรับตัว SQL พื้นฐาน 80% เหมือน อีก 20% ที่ vendor-specific คือสิ่งที่ทำให้ migration ของจริงยาก
มุมผู้บริหาร เวลาทีมคุณบอกว่า “ระบบเราใช้ SQL standard ย้าย vendor ง่าย” ฟังให้ดีก่อนเชื่อ ถ้าระบบมี stored procedure เยอะ มี trigger เยอะ มี view ซับซ้อน สิ่งพวกนี้มักเขียนใน vendor-specific extension ค่า migration อาจจะแพงกว่าที่ทีมประเมิน 5-10 เท่า
ทีนี้ในระหว่างที่ SQL กำลัง standardize ตลาด database enterprise ก็แบ่งกันชัดเจน มีผู้เล่น 4 รายใหญ่ที่ครอง 90% ของตลาด
Big 4 ของยุค — ใครครองตลาดอะไร
ยุค 80s ปลายถึง 90s ตลาด database enterprise มี Big 4 ที่ทุกบริษัทใหญ่ในโลกเลือกใช้ แต่ละเจ้าครองตลาดคนละมุม
Oracle — เจ้าของวงการ enterprise + government
Oracle Database เป็นพี่ใหญ่ของวงการตั้งแต่ยุคนั้นจนถึงปัจจุบัน จุดแข็งคือ feature ครบที่สุด performance สูงที่สุดสำหรับงาน enterprise ขนาดใหญ่ support 24/7 ที่บริษัทขนาด Fortune 500 ต้องการ
ลูกค้าหลัก: ธนาคารใหญ่, รัฐบาล, telecom (เช่น AT&T, Verizon), สายการบิน (American Airlines, United)
จุดที่คนรัก/เกลียด Oracle: ราคาแพงมาก license หลักล้านบาทต่อ CPU support สัญญารายปี 22% ของค่า license audit license ที่เข้มงวดจน CFO กลัว แต่มันทำงานได้จริง และสำหรับธนาคารที่จัดการเงินวินาทีละล้านดอลลาร์ ความน่าเชื่อถือสำคัญกว่าราคา
ในประเทศไทย ธนาคารใหญ่หลายแห่ง การไฟฟ้า การประปา ระบบภาษี ระบบประกันสังคม ส่วนใหญ่ run บน Oracle ตั้งแต่ยุค 90s ถึงทุกวันนี้
Microsoft SQL Server — Windows ecosystem + SMB
Microsoft SQL Server เกิดในปี 1989 จากความร่วมมือระหว่าง Microsoft กับ Sybase (อ่านต่อข้างล่าง) Microsoft ซื้อ engine มาจาก Sybase ทำเวอร์ชันสำหรับ Windows แล้วค่อยๆ พัฒนาเป็นของตัวเอง
จุดแข็ง: ราคาถูกกว่า Oracle 3-5 เท่า integrate กับ Windows + .NET + Excel + Active Directory ได้สบาย GUI ใช้ง่าย (Management Studio ที่ admin คนใหม่หัดได้เร็ว)
ลูกค้าหลัก: ธุรกิจขนาดกลาง (SMB) ที่ใช้ Windows ecosystem อยู่แล้ว แผนก finance ของบริษัทใหญ่ที่ทำ data analysis
ในไทย บริษัทขนาดกลางที่ใช้ระบบบัญชีบน Windows ระบบ POS ระบบโรงแรม ระบบโรงงาน SMB ส่วนใหญ่อยู่บน SQL Server
IBM DB2 — mainframe + banking ที่ใหญ่มาก
IBM DB2 เป็น database ของ IBM ที่ run อยู่บน mainframe (คอมพิวเตอร์ขนาดยักษ์ที่ IBM ขายให้บริษัทระดับโลก) DB2 รัน transaction ได้หลายหมื่นต่อวินาทีบน hardware ตัวเดียว ที่ราคาเป็นร้อยล้านบาทต่อตู้
ลูกค้าหลัก: ธนาคารโลกระดับ HSBC, JP Morgan, Bank of America, สายการบินใหญ่, บริษัทประกันยักษ์, ระบบจองตั๋วของ airline industry (เช่น Sabre, Amadeus)
ทำไม DB2 ยังอยู่ปี 2026: เพราะระบบ core banking ของธนาคารใหญ่ในโลก ย้ายไม่ได้ มันเขียนใน COBOL run บน mainframe ใช้ DB2 ทำงานมา 30-40 ปี ทุกบรรทัด code ผ่านการทดสอบมาทุกซอกทุกมุม การเขียนใหม่ใช้เวลา 5-10 ปี + งบหลายพันล้าน + ความเสี่ยงที่ระบบใหม่จะมี bug ที่ระบบเก่าไม่มี หลายธนาคารเลือกที่จะ “ของเก่ายังทำงานอยู่ก็พอ”
Sybase — Wall Street + financial trading
Sybase เป็นเจ้าที่คนนอกวงการ finance อาจจะไม่คุ้น แต่ในยุค 90s มันคือเจ้าของ Wall Street เลยครับ ระบบ trading ของ investment bank ใหญ่เกือบทุกแห่งใน New York ใช้ Sybase เพราะ Sybase ออกแบบมาให้รับมือกับ transaction ที่เร็วและถี่มาก ราคาหุ้นเปลี่ยนวินาทีละพันครั้ง
เคสที่น่าสนใจของ Sybase: ปี 1989 Microsoft จับมือกับ Sybase ทำ database สำหรับ OS/2 (เวอร์ชันแรกของ Windows server) ปี 1994 ทั้งสองเลิกกัน Microsoft ได้สิทธิ์เอา engine ไปพัฒนาต่อเป็น SQL Server Sybase แยกไปทำ ASE (Adaptive Server Enterprise) ของตัวเอง ปี 2010 SAP ซื้อ Sybase ในราคา $5.8 พันล้านดอลลาร์ ปัจจุบัน Sybase กลายเป็นส่วนหนึ่งของ SAP HANA
มุมผู้บริหาร ถ้าระบบ trading หรือระบบ legacy ของบริษัทคุณยังใช้ Sybase อยู่ รู้ไว้เลยว่า skill engineer Sybase หายากขึ้นเรื่อยๆ และ migration plan ควรอยู่ในแผน 3-5 ปีข้างหน้า
ทีนี้พอ Big 4 ครองตลาด database สิ่งที่เปลี่ยนตามมาคือ วิธีที่บริษัทใช้ database และตรงนี้ที่ ERP เข้ามาเปลี่ยนภาพใหญ่ของวงการ
ERP Boom ของยุค 90s — database = backbone ของธุรกิจ
ก่อนยุค 90s บริษัทใหญ่หนึ่งบริษัทมักจะมี database หลายตัวที่ไม่คุยกัน ฝ่ายบัญชีใช้ระบบหนึ่ง ฝ่ายขายใช้อีกระบบ ฝ่ายคลังสินค้าใช้อีกระบบ ฝ่าย HR ใช้ Excel ทุกฝ่ายเก็บข้อมูลของตัวเอง รายงานของตัวเอง ทำงานในกล่องของตัวเอง
ปัญหาคือ เวลาผู้บริหารถามว่า “เดือนนี้กำไรเท่าไหร่?” ต้องรอเดือนหน้าค่อยรู้ เพราะต้องรวมข้อมูลจาก 5 ระบบที่เก็บคนละแบบ แต่ละฝ่ายปิดงบคนละวัน ตัวเลขไม่ตรงกัน ผู้บริหารตัดสินใจช้า แข่งกับคู่แข่งไม่ทัน
ปี 1992 บริษัทเยอรมันชื่อ SAP ออก R/3 ระบบ ERP (Enterprise Resource Planning) ที่เปลี่ยนสมมติฐานใหญ่ของวงการ แนวคิดคือ ทุกฝ่ายของบริษัทใช้ database เดียวกัน
- ฝ่ายขายขายของ → record ลง database กลาง
- ฝ่ายคลังหักสต๊อก → record ลง database เดียวกัน
- ฝ่ายบัญชีออก invoice → ดูจาก record ของฝ่ายขาย โดยอัตโนมัติ
- ฝ่ายผลิตวางแผน → ดูจาก demand ของฝ่ายขาย, สต๊อกของฝ่ายคลัง พร้อมกัน
- ผู้บริหารดู dashboard → ดูทุกฝ่ายในหน้าจอเดียว real-time
นี่แหละสิ่งที่วงการเรียกว่า single source of truth มีแหล่งข้อมูลเดียวที่ทุกคนเชื่อ ไม่ต้องไปประสานข้อมูลระหว่างฝ่าย
คู่แข่งของ SAP ในยุคนั้น: Oracle E-Business Suite (Oracle EBS), PeopleSoft (HR-focused ภายหลัง Oracle ซื้อ), JD Edwards (manufacturing-focused ภายหลัง Oracle ซื้อเช่นกัน) ปลายยุค 90s ถ้าบริษัทใหญ่ระดับโลกไหนยังไม่มี ERP จะถูกมองว่า “ตกยุค”
ทำไม ERP implementation cost สูงมาก
ตรงนี้เป็นจุดที่ผู้บริหารหลายคนเข้าใจผิด ค่า implement ระบบ ERP ของ SAP ขนาดใหญ่ มักจะอยู่ที่ 100 ล้านบาทถึง 1,000 ล้านบาท สำหรับบริษัทขนาดใหญ่ แต่ค่า license SAP เองอาจจะแค่ 10-20% ของก้อนนั้น
แล้วอีก 80% หายไปไหน?
- Data migration ย้ายข้อมูลจากระบบเก่า 5-10 ระบบ มาอยู่ใน SAP ตัวเดียว ข้อมูลเก่าจัดเก็บคนละ format ต้อง clean ต้อง map field ต้อง validate ส่วนนี้กินเวลา 6-18 เดือน + จ้าง consultant ราคาแพงมาก
- Process re-engineering SAP มี “วิธีการที่ best practice” ของมัน ถ้าบริษัทอยากให้ SAP ทำตามวิธีเดิมของบริษัท ต้อง customize ซึ่งราคาแพง + ทำให้ upgrade ยาก ทางเลือกคือบริษัทเปลี่ยน process ของตัวเองให้ตรงกับ SAP (cheaper) หรือตามใจบริษัท (expensive)
- Training พนักงานทุกคนทุกฝ่ายต้องเรียนใช้ SAP คนที่ใช้ระบบเก่ามา 20 ปี ต้องลืมและเรียนใหม่
- Change management แผนกที่เคยมี “อำนาจในกล่องตัวเอง” เสียอำนาจให้ระบบกลาง resistance ทางการเมืองภายในองค์กร มักเป็นสิ่งที่ทำให้ ERP project fail มากกว่าปัญหาทาง technical
มุมผู้บริหาร ถ้าใครเคยเห็นโครงการ ERP ของบริษัทใหญ่ที่ “เลื่อนไป 2 ปีแล้วยังไม่ go-live” สาเหตุ 80% ไม่ใช่ technical เป็นเรื่อง process + change management ล้วนๆ
ทีนี้พอ database = backbone ของบริษัท + ERP กลายเป็นมาตรฐาน ก็ต้องการคนใหม่ในองค์กร คนที่ดูแลกุญแจของห้องเก็บเงิน ห้องเก็บข้อมูลลูกค้า ห้องเก็บข้อมูลพนักงาน ทั้งหมดในที่เดียว
การเกิดของ DBA Role
ก่อนยุค 90s คนที่ดูแล database คือ “programmer ที่บังเอิญรู้ database” ทำงานควบไป ไม่ใช่ specialty ของตัวเอง แต่พอ database กลายเป็น single source of truth ของทั้งบริษัท บริษัทใหญ่เริ่มรู้ตัวว่ามันเสี่ยงเกินไปที่จะให้ programmer ที่ทำงานหลายอย่างมาดูแล “ห้องเก็บเงิน” ของบริษัท
ตำแหน่งใหม่จึงเกิดมา ชื่อ DBA (Database Administrator) คนที่ถือกุญแจทุกดอกของ database
ความรับผิดชอบของ DBA:
- Backup + Restore ถ้า database พังวันนี้ จะกู้คืนภายในกี่ชั่วโมง? ข้อมูลล่าสุดอยู่ที่ snapshot เมื่อไหร่?
- Performance Tuning query ของฝ่ายไหนช้า? ต้องสร้าง index ตรงไหน? ตารางไหน normalize เกินไป?
- Security ใครเข้าถึง table ไหนได้? พนักงานลาออกแล้ว revoke access แล้วยัง? log การเข้าใช้ครบไหม?
- Capacity Planning สิ้นปีหน้า database จะใหญ่เท่าไหร่? disk พอไหม? ต้องซื้อ server เพิ่มเมื่อไหร่?
- Disaster Recovery ถ้า data center ไฟไหม้ มี backup ที่อีก site ไหม? ใช้เวลากู้กี่ชั่วโมง?
- Schema Migration ตอน developer อยากเพิ่ม column ใหม่ในตารางที่มีข้อมูล 100 ล้านแถว ทำยังไงไม่ให้ระบบล่ม
ทำไม DBA = paid well? เพราะ skill นี้หายาก รับผิดชอบสูง ผิดครั้งเดียวบริษัทเสียเงินหลักล้านถึงร้อยล้าน
ทำไม DBA = scarce talent? เพราะการจะเก่ง DBA ต้องผ่านประสบการณ์จริงหลายปี ไม่ใช่อ่านหนังสือเรียนได้ ต้องเคยกู้ database ที่พังกลางคืน เคย tune query ของระบบที่มีคนใช้พร้อมกันเป็นหมื่น เคยออกแบบ schema ที่รับการเติบโต 10 เท่าได้
ทำไม DBA = single point of failure? เพราะ DBA คนเดียวมักรู้ทุกอย่างเกี่ยวกับ database ของบริษัท ถ้า DBA ป่วย ลาออก ไม่พอใจ บริษัทมีความเสี่ยงสูงมาก และถ้า DBA ที่มีอำนาจสูงสุด decide จะทำเรื่องไม่ดี เขาเข้าถึงข้อมูลทุกคน ลบทิ้งทั้ง database ได้ในคำสั่งเดียว ดู transaction ของผู้บริหารได้
นี่แหละ pattern ที่ในวงการเรียกว่า privileged access risk บัญชีที่มีอำนาจสูง = ความเสี่ยงสูงสุดในระบบ (เรื่องนี้จะเจาะลึกใน EP.13 — DBA Role + Privileged Access ที่จะคุยเรื่อง separation of duty, audit log, just-in-time access ฯลฯ)
มุมผู้บริหาร — ทำไมระบบ legacy ไทยปี 2026 ยังเต็มไปด้วย Oracle
ตรงนี้เป็นคำถามที่ผู้บริหารไทยหลายคนเจอ ทำไมระบบ core ของธนาคาร ของรัฐ ของบริษัทใหญ่ ยัง run บน Oracle/DB2 ยุค 90s ทั้งๆ ที่ตอนนี้มี cloud database ใหม่เต็มตลาด?
คำตอบไม่ใช่เพราะทีม IT ขี้เกียจครับ มันคือสมการเศรษฐศาสตร์ที่จริง
Cost of staying (ต้นทุนที่ไม่ย้าย):
- ค่า license Oracle ปีละหลายสิบล้านบาท
- ค่า support ปีละหลายล้านบาท
- ค่า DBA + engineer ที่หายากขึ้น
- ความเสี่ยงที่ vendor จะขึ้นราคา
Cost of migration (ต้นทุนถ้าย้าย):
- เขียน application ใหม่หลายหมื่นบรรทัด งบหลักร้อยล้านถึงพันล้าน
- ทดสอบทุก edge case ที่ระบบเก่าทำงานมา 30 ปี งบ + เวลาที่คาดเดายาก
- ความเสี่ยงที่ระบบใหม่มี bug ที่ระบบเก่าไม่มี risk = หายนะถ้าธนาคารคิดยอดผิด
- ความเสี่ยงทาง compliance regulator อาจไม่อนุมัติระบบใหม่ทันเวลา
- เวลาที่ทีมต้องทุ่มไปกับ migration แทนที่จะพัฒนาฟีเจอร์ใหม่ opportunity cost
ในสมการนี้ “ของเก่ายังทำงานอยู่ก็พอ” mentality ชนะเกือบทุกครั้ง ตราบใดที่ระบบเก่ายัง run ได้ ผู้บริหารส่วนใหญ่จะเลือกไม่เสี่ยง
แล้วเมื่อไหร่ที่ legacy migration กลายเป็น must? มี 4 trigger หลัก
- Vendor stop support Oracle ประกาศ end-of-life ของเวอร์ชันที่ใช้อยู่ ถ้าไม่ upgrade ไม่มี security patch
- Compliance requirement กฎหมายใหม่บังคับ feature ที่ระบบเก่าทำไม่ได้ (เช่น PDPA / GDPR / data residency)
- Security incident ระบบเก่าโดน hack หรือมี vulnerability ใหญ่ที่แก้ไม่ได้ในเวอร์ชันเก่า
- Skill shortage critical หาคน maintain ระบบเก่าไม่ได้แล้ว เพราะ engineer ที่รู้เกษียณหมด
ก่อนถึง 4 จุดนี้ บริษัทส่วนใหญ่จะอยู่กับระบบเดิม นี่แหละเหตุผลที่ Oracle/DB2/SAP จาก 30 ปีที่แล้ว ยังเป็นกระดูกสันหลังของวงการธุรกิจไทยและทั่วโลกในปี 2026
ปิดบท + ข้ามไป EP.04
EP.03 จบที่นี่ครับ 1980s-90s คือทศวรรษที่ relational database ไม่ได้แค่ชนะการประกวด แต่ ครองวงการเบ็ดเสร็จ ACID ทำให้ธนาคารกล้าเลิกจ้างคนเทียบมือตอนเย็น SQL standardization ทำให้ skill transferable Big 4 (Oracle / SQL Server / DB2 / Sybase) ครอง 90% ของตลาด ERP boom เปลี่ยน database เป็น single source of truth ของบริษัทใหญ่ทั้งโลก DBA กลายเป็นตำแหน่งงานใหม่ที่ paid well + scarce + risky ปี 2000 ใครพูดเรื่อง database เขาหมายถึง relational จบเรื่อง
แต่… ในห้องสัมมนาเล็กๆ ที่ Berkeley ปี 2000 มีอาจารย์คนหนึ่งโยนทฤษฎีหนึ่งทิ้งไว้ ที่จะกลายเป็นกฎเหล็กบังคับให้วงการต้องเลือกข้าง ปี 2006 มี paper หนึ่งหลุดออกมาจาก Google ปี 2007 มีอีกหนึ่งหลุดมาจาก Amazon และปี 2008 Twitter ล่มทุกสัปดาห์จนภาพปลาวาฬสีฟ้ากลายเป็น meme ของวงการ
เรื่องราวพวกนี้บอกเรื่องเดียวกัน relational database ที่ครองวงการมา 20 ปี ที่ทุกคนคิดว่า “ครบเครื่องแล้ว” มันมีจุดหนึ่งที่มันรับไม่ไหว จุดนั้นเรียกว่า Web Scale เว็บที่มี user เป็นร้อยล้านคนเข้าใช้งานพร้อมกัน พอ relational ไปไม่ไหว โลกก็ได้ database พันธุ์ใหม่ที่ชื่อ NoSQL
EP.04 เราจะข้ามไปยุค 2000s-2010s มาดูกันว่าทำไม relational ถึง scale แนวนอนไม่ไหว CAP theorem บังคับให้เลือก trade-off อย่างไร NoSQL 4 ตระกูล มีอะไรบ้าง และทำไม Hadoop ที่เคยเป็นพระเอกของยุค Big Data ถึง fade ไปอย่างรวดเร็วหลังปี 2015
→ EP.04 — ยุค 2000s-2010s: NoSQL Movement + Big Data (เมื่อ Web Scale ทำลาย Relational)
