Database 101 EP.02 — ยุค 1960s-70s: Hierarchical → Relational Revolution (Codd Paper ที่เปลี่ยนโลก)

Series: Database 101 — เข้าใจห้องสมุดของเมืองดิจิทัล (ภาษาคน)

Part 0 — WHY: ทำไมต้องมีห้องสมุด

EP.01 — ทำไมต้องมี Database: โลกก่อนมีห้องสมุด

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.01 เราจบที่คำถามใหญ่ครับ — ก่อนปี 1960 โลกไม่มี “database” ในความหมายที่เราใช้กันทุกวันนี้ ข้อมูลขององค์กรอยู่ในตู้เหล็ก ในแฟ้มกระดาษ ในเทปแม่เหล็กที่อ่านลำดับเดียว แล้วอยู่ๆ ในทศวรรษ 1960-70 ห้องสมุดของเมืองดิจิทัลก็โผล่ขึ้นมา โผล่ขึ้นมาแบบที่ไม่มีใครย้อนกลับได้อีกเลย

EP.02 คือเรื่องของทศวรรษนั้น ทศวรรษที่ database “เกิด” สองรอบ รอบแรกเกิดเพราะ NASA ส่งคนไปดวงจันทร์ และต้องการระบบที่เก็บชิ้นส่วนยานเป็นล้านชิ้นโดยห้ามผิดแม้แต่ตัวเดียว รอบที่สองเกิดเพราะนักคณิตศาสตร์คนหนึ่งใน IBM อ่านงานของบริษัทตัวเองแล้วทนไม่ไหว เขียน paper ฉบับเดียวที่ภายหลังกลายเป็นรากฐานของ database เกือบทุกตัวที่คุณรู้จักวันนี้

มาเริ่มที่ฉากแรกกันก่อน ตอนที่ทุกอย่างยังไม่มีคำตอบ

ฉากเปิด: NASA Apollo Program (1960s)#

ปี 1961 ประธานาธิบดี Kennedy ขึ้นเวทีแล้วประกาศกับโลกว่า สหรัฐจะส่งคนไปเหยียบดวงจันทร์ภายในสิ้นทศวรรษนี้ คำพูดสั้นๆ แต่เบื้องหลังมันสร้างปัญหาที่ไม่มีใครในโลกเคยเจอมาก่อน

ยานอวกาศ Saturn V ที่จะพาคนไปดวงจันทร์ มีชิ้นส่วนประมาณ 3 ล้านชิ้น แต่ละชิ้นมีหมายเลข มีผู้ผลิต มีวันที่ตรวจ มีสเปกที่ต้องตรงเป๊ะ และเงื่อนไขที่โหดที่สุดคือ ถ้าผิดแม้แต่ชิ้นเดียว นักบินอวกาศตาย ไม่มี second chance ไม่มี customer service ไม่มีโอกาสซ่อมกลางทาง

NASA เลยหันไปขอความช่วยเหลือจาก IBM คำถามที่โยนใส่ทีมวิศวกรของ IBM คือ “เก็บข้อมูลขนาดนี้ยังไง ให้หาเจอได้ทันที + ไม่ผิด?” ตอนนั้นคำว่า “database” ยังไม่มีในพจนานุกรม IT เลยด้วยซ้ำ ทีม IBM ต้องคิดทุกอย่างจากศูนย์

ผลจากโจทย์นี้ ปี 1968 IBM ก็ปล่อย IMS (Information Management System) ออกมาช่วย NASA รัน Apollo และนั่นแหละคือ database เชิงพาณิชย์ตัวแรกที่มีคนใช้จริงในโลก

ยุค Hierarchical (1960s) — IBM IMS (1968)#

แนวคิด: ข้อมูลถูกจัดเก็บเป็น “ต้นไม้” มี root อยู่บนสุด แล้วแตกกิ่งลงมาเป็น branch แล้วแตกย่อยลงไปอีกเป็น leaf ทุกอย่างมีพ่อแม่ลูก ลำดับชั้นชัดเจน

เปรียบเทียบ: ลองนึกถึง folder ใน Windows Explorer ครับ คุณเปิด My Computer → Drive C → Program Files → Microsoft → Office → winword.exe ทุกไฟล์อยู่ในโฟลเดอร์เดียว ทุกโฟลเดอร์มีโฟลเดอร์แม่ หรือถ้าให้ใกล้ตัวกว่านั้น ก็เหมือน ต้นไม้ตระกูล ที่มีปู่อยู่บนสุด ลูก หลาน เหลน ลดหลั่นลงมา

ในเคสของ NASA โครงสร้างจะประมาณนี้

1
Saturn V Rocket  (root)
2
├── Stage 1
3
│   ├── Engine F-1 (×5)
4
│   │   ├── Fuel Pump
5
│   │   │   ├── Bearing Type A
6
│   │   │   └── Screw Type B (×42)
7
│   │   └── Combustion Chamber
8
│   └── Fuel Tank
9
├── Stage 2
10
└── Stage 3

ข้อดี — ทำไม IMS เก่งสำหรับ NASA:

เร็ว ถ้ารู้เส้นทางลงมาในต้นไม้ เดินตรงไปถึง leaf ภายใน milliseconds
โครงสร้างชัด ทุกชิ้นส่วนมีพ่อแม่ของมัน ไม่หลงทาง
คาดเดาผลได้ query ตัวเดิม ใช้เวลาเท่าเดิมเสมอ ในงาน mission-critical แบบ Apollo ความ predictable นี้สำคัญกว่าความเร็วเสียอีก

ข้อเสีย — และนี่คือจุดที่จะเป็นปัญหาในอนาคต:

เปลี่ยน schema ยากมาก ถ้าวันหนึ่งวิศวกรอยากเพิ่ม field “supplier country” ลงไปในทุกชิ้นส่วน ต้อง redesign ต้นไม้ใหม่ทั้งต้น เขียนโปรแกรมใหม่ทุกตัวที่ access ต้นไม้นี้
Query ต้อง “เขียนเส้นทาง” เอง โปรแกรมเมอร์ต้องเขียนโค้ดบอกว่า “ไป root → ลง stage 1 → ลง engine → ลง fuel pump → หยิบ screw type B” ภาษาเทคนิคเรียกว่า navigational query บอกวิธีไปหา ไม่ใช่บอกว่าอยากได้อะไร
ความสัมพันธ์ที่ไม่ใช่พ่อแม่ลูกทำยาก ถ้าชิ้นส่วน A ใช้ใน engine และใช้ในระบบลงจอดด้วย hierarchical ทำได้ลำบาก เพราะมันออกแบบให้ทุก leaf มีพ่อแม่คนเดียว

มุมผู้บริหาร: ลองถามคนในวงการธนาคารไทยปี 2026 ว่า “ระบบหลังบ้านของคุณรันบนอะไร” หลายเคสคำตอบยังเป็น mainframe + IMS ที่เริ่มใช้มาตั้งแต่ทศวรรษ 1980 ไม่ใช่เพราะดีที่สุด แต่เพราะ migrate ออกยากเกินไป ระบบ legacy ที่รันมา 30-40 ปี เก็บ business logic ไว้ในรูปแบบที่ไม่มีใครเหลือคนเข้าใจครบทั้งหมดแล้ว ค่า migrate รวมความเสี่ยง บางเคสประเมินได้เป็นพันล้าน นี่แหละเหตุผลที่ของ “ตกยุคทางเทคนิค” บางอย่างก็ยังอยู่ เพราะธุรกิจรับ downtime ของการเปลี่ยนไม่ได้

Keywords: Hierarchical Model, IMS, Tree Structure, Navigational Query

Network Database (CODASYL standard, 1969)#

ปี 1969 มีกลุ่ม committee ชื่อ CODASYL (กลุ่มเดียวกับที่กำหนดมาตรฐานภาษา COBOL) ออกมาตรฐานใหม่ แนวคิดคือ hierarchical ดีแล้ว แต่บังคับให้ทุก leaf มีพ่อแม่คนเดียว มันคับเกินไป ลองทำเป็น graph ดูสิ node หนึ่งเชื่อมไปได้หลายทิศ ไม่จำกัดแค่พ่อแม่ลูก

เปรียบเทียบ: ถ้า hierarchical เหมือนต้นไม้ตระกูล Network database ก็เหมือน ผังเครือญาติของหนังตระกูลใหญ่ ที่มีการแต่งงานข้ามตระกูล มีลูกบุญธรรม มีพี่เลี้ยงที่ใกล้ชิดเหมือนญาติ เส้นความสัมพันธ์เชื่อมไปมาได้หลายแบบ ไม่ตายตัว

ข้อดีคือยืดหยุ่นกว่า hierarchical จริง ข้อเสียคือ ซับซ้อนกว่ามาก โปรแกรมเมอร์ต้องเขียน navigational code ที่ยุ่งกว่าเดิม เพราะตอนนี้มี “เส้นทาง” หลายเส้นให้เลือก

ที่ผมต้องเล่าตระกูลนี้ให้ฟังเพราะมันเป็น ขั้นกลาง ของวิวัฒนาการครับ คนพยายามแก้ปัญหาของ hierarchical แต่ยังคิดไม่ออกว่าจะข้าม paradigm ของ navigational ไปยังไง ทุกวันนี้ระบบใหม่แทบไม่เห็น Network database แล้ว ส่วนใหญ่อยู่ใน legacy system เก่าๆ ของ mainframe มันคือทางสายที่วงการลองเดินแล้วพบว่า “ทางตัน”

แต่ระหว่างที่วงการยังถกกันเรื่อง hierarchical vs network มีนักคณิตศาสตร์คนหนึ่งใน IBM นั่งคิดอีกแบบ และความคิดของเขาจะ disrupt ทุกอย่าง

The Codd Paper (1970) — จุดเปลี่ยนวงการ#

Edgar F. Codd เป็นนักคณิตศาสตร์ชาว British ที่ทำงานอยู่ที่ IBM Research San Jose background เขาคือคณิตศาสตร์เชิง logic ไม่ใช่วิศวกรซอฟต์แวร์ เขามองโลก database ของยุคนั้นแล้วรู้สึกว่า “ผิดทางหมด”

ปัญหาที่เขาเห็นคือ ทั้ง hierarchical และ network บังคับให้โปรแกรมเมอร์ต้อง “รู้โครงสร้าง” ก่อนถึงจะ query ได้ ถ้าวันไหนโครงสร้างเปลี่ยน ต้องเขียนโปรแกรมใหม่ทั้งหมด นั่นแปลว่า business logic กับ data structure ผูกกันแน่นจนแยกไม่ออก ในมุมคณิตศาสตร์มันไม่ make sense เลย

ปี 1970 Codd เผยแพร่ paper ชื่อ “A Relational Model of Data for Large Shared Data Banks” ใน journal ของ ACM paper สั้นๆ ไม่ถึง 20 หน้า แต่ในนั้นมีแนวคิดที่จะเปลี่ยนวงการไปตลอดกาล

แนวคิดของ Codd — ข้อมูลคือ “ตาราง”#

แนวคิดหลัก:

ข้อมูลทุกอย่างคือ “ตาราง” (table) มี row (แถว = หนึ่ง record) และ column (คอลัมน์ = field) จบ ไม่มีต้นไม้ ไม่มี graph ไม่มี pointer
ความสัมพันธ์ระหว่างตาราง = key ไม่ใช่ pointer ที่ “ชี้ไปที่อยู่ใน memory” แต่เป็น “ค่าที่ตรงกัน” เช่น ตาราง Order มี column customer_id ที่ค่าตรงกับ id ในตาราง Customer
Operation บน relational ใช้ algebra มีกฎทางคณิตศาสตร์รองรับ คุณ JOIN, FILTER, PROJECT ตารางได้แบบที่พิสูจน์ได้ในเชิง logic ว่าผลลัพธ์ถูกต้อง

เปรียบเทียบ: ถ้า hierarchical คือต้นไม้ตระกูลที่ทุกคนมีพ่อแม่ relational เหมือน บัตรประชาชนของพลเมืองในประเทศ แต่ละคนคือหนึ่งแถวในตารางทะเบียนราษฎร์ มี ID เลข 13 หลัก ถ้าจะหาว่าใครเป็นเจ้าของรถทะเบียน กข-1234 ก็ไปดูตารางทะเบียนรถ หาเลขเจ้าของ แล้วเอาเลขนั้นไป lookup ในตารางทะเบียนราษฎร์ ไม่มี “ต้นไม้” ระหว่างคนกับรถ มีแค่ “เลขที่ตรงกัน”

แนวคิดสำคัญที่สุด — Declarative#

นี่แหละจุดที่ต้องเน้นครับ เพราะมันคือเหตุผลจริงๆ ที่ relational ชนะ hierarchical

ในโลก hierarchical/network โปรแกรมเมอร์ต้องเขียน navigational query บอกวิธีไปหา “ไป root → ลง branch ที่ 3 → loop หา leaf ที่ field A = X → คืนค่า field B”

ในโลก relational โปรแกรมเมอร์เขียน declarative query บอกแค่ว่าอยากได้อะไร “SELECT name FROM customer WHERE country = ‘Thailand’” แค่นั้น ไม่ต้องบอกว่าจะไปหาด้วยวิธีไหน database จะคิดเส้นทางที่เร็วที่สุดให้เอง

ความต่างนี้ฟังดูเล็ก แต่ผลลัพธ์มหาศาล:

โปรแกรมเมอร์ไม่ต้องเข้าใจโครงสร้างภายใน database
เปลี่ยนโครงสร้างภายในได้โดยไม่ต้องไปแก้ application
database optimizer ปรับวิธีค้นหาได้เอง เร็วขึ้นโดยไม่ต้องแก้โค้ด
ภาษาที่ใช้ query เรียนง่าย (พูดเป็นภาษาคน อ่านเข้าใจ)

relational ชนะ hierarchical ไม่ใช่เพราะ “ดีกว่า” แต่เพราะ “declarative” แทน “navigational” นี่แหละ thesis หลักของบทนี้ ขอให้จำตรงนี้ไว้

ทำไมแนวคิดนี้ “ขัดใจ IBM” ตอนแรก#

ตลกร้ายของเรื่องคือ Codd ทำงานอยู่ใน IBM และ IBM ในปี 1970 = บริษัทที่ลงทุนกับ IMS ไปแล้วมหาศาล การที่พนักงานของตัวเองออก paper บอกว่า “วิธีที่บริษัทขายอยู่ มันผิด paradigm หมด” ไม่ใช่ข่าวดีในห้องประชุมผู้บริหาร IBM แน่ๆ

ผู้บริหาร IBM ตอนนั้นพยายาม “เก็บ” idea ของ Codd ไว้ภายในบริษัท ไม่อยากให้ใช้ทำลาย business ของ IMS ที่กำลังขายดี แต่ paper ตีพิมพ์แล้วในวารสารวิชาการ ใครก็อ่านได้ และจะมีคนนอก IBM ที่อ่านแล้วเห็นโอกาส

System R (1974-1979) — IBM Research project#

ในที่สุด IBM ก็ตัดสินใจให้ทีม research ลองทำ prototype ของ relational database โปรเจกต์ชื่อ System R เริ่มที่ IBM Research San Jose ปี 1974

System R เป็น prototype แรกของ relational database จริงๆ ในโลก และระหว่างที่ทีมพัฒนา พวกเขาสร้างภาษา query ขึ้นมาตัวหนึ่งเพื่อให้คนใช้ง่ายๆ ภาษานั้นชื่อเดิมว่า SEQUEL (Structured English Query Language) ภายหลังเปลี่ยนชื่อเหลือ SQL เพราะติดเรื่องเครื่องหมายการค้า

นี่แหละครับ SQL กำเนิดใน System R ของ IBM ภาษาที่ทุกวันนี้ programmer/data analyst/business analyst ทั่วโลกใช้คุยกับ database เกิดจาก research project ที่บริษัทตัวเองยังไม่กล้าปล่อยขาย

ทำไม IBM ไม่ปล่อย System R เป็น product? สั้นๆ คือ ผลประโยชน์ขัดกัน IMS ขายดี กำลังเป็นกระดูกสันหลังของลูกค้าใหญ่ทั่วโลก ถ้า IBM ออก relational database ของตัวเองมาตอนนี้ เหมือนยิงเท้าตัวเอง สั่งห้ามลูกค้า IMS ย้ายมา relational ของ IBM เองไม่ได้ แต่อยากให้ลูกค้าอยู่กับ IMS ต่อให้นานที่สุด

ผลคือ IBM ปล่อย System R เป็น research paper หลายชุด ปล่อย demo ไปให้มหาวิทยาลัยใช้ แต่ไม่ทำเป็น commercial product จนถึงปี 1983 (DB2)

และช่องว่างตรงนี้ มีคนนอก IBM กำลังจ้องอยู่

Oracle 1979 — relational DB เชิงพาณิชย์ตัวแรก#

Larry Ellison เป็น sales engineer วัย 30 กว่าๆ ทำงานอยู่ที่บริษัท software เล็กๆ ใน California ปี 1977 เขาอ่าน paper ของ Codd และ paper เกี่ยวกับ System R ของ IBM แล้วก็เห็นโอกาสทันที

Ellison ตั้งบริษัทใหม่ชื่อ Software Development Laboratories (ภายหลังเปลี่ยนเป็น Oracle Corporation) กับเพื่อน 2 คน เป้าหมายชัดเจน สร้าง relational database เชิงพาณิชย์ตัวแรกของโลก ก่อน IBM ทำเอง

ปี 1979 บริษัทปล่อย Oracle V2 ออกขาย (V1 ไม่ได้ปล่อยจริง นับเริ่มที่ V2 เพราะกลัวลูกค้าไม่เชื่อใจ V1) database เชิงพาณิชย์ relational ตัวแรกของโลกออกสู่ตลาดอย่างเป็นทางการ

ลูกค้าแรก: CIA#

case classic ของวงการคือ ลูกค้ารายแรกของ Oracle คือ CIA (สำนักข่าวกรองกลางของสหรัฐ) CIA ต้องการ database ที่ค้นหาข้อมูลข่าวกรองได้ flexible กว่า hierarchical และยอมเสี่ยงใช้ของ vendor เล็กๆ ที่เพิ่งเปิด

นี่แหละ pattern ที่จะวนซ้ำในวงการเทคโนโลยีอีกหลายรอบ ของใหม่ที่ disruptive จะถูก adopt ครั้งแรกโดยลูกค้าที่มี problem โหดที่ของเดิมตอบไม่ได้ ส่วนลูกค้าทั่วไปจะรอดูสักพักก่อน

ทำไม Oracle ชนะ IBM ในตลาด — ทั้งที่ IBM เป็นคนคิดทฤษฎีเอง#

เรื่องนี้สอนใจเจ้าของกิจการครับ IBM เป็นคนคิด relational, สร้าง System R, เกิด SQL, มีทีม research ที่เก่งที่สุดในโลก แต่สุดท้าย Oracle เป็นคนกินตลาด ทำไม?

3 เหตุผล:

Speed of execution Oracle ปล่อย product ออกขายปี 1979 IBM ปล่อย DB2 ปี 1983 ช่องว่าง 4 ปีนั้น Oracle หาลูกค้าแรกๆ ของวงการได้หมด ทั้ง CIA, รัฐบาล, กระทรวงกลาโหม, ธนาคาร พอ IBM ลงสนาม ช้าไปแล้ว
โฟกัส 100% Oracle มี product เดียว = relational database ทุกบาทที่ลงทุนไปกับมัน ส่วน IBM มี product เป็นร้อย relational เป็นแค่หนึ่งในนั้น และยัง conflict กับ IMS อีก
Sales aggressive Ellison เป็นนักขายโดยกำเนิด เขาขาย vision มากกว่าขายของ บอกลูกค้าว่า “ของฉันทำได้ทุกอย่าง” ก่อนจะทำได้จริงๆ แล้วค่อยกลับมาพัฒนาให้ทันคำสัญญา

บทเรียน: การคิดได้ก่อน ไม่เท่ากับ การทำได้ก่อน IBM “เป็นเจ้าของไอเดีย” ของ relational แต่เพราะกลัวกระทบ business เก่า เลยลงสนามช้า ในวงการเทคโนโลยี first-mover advantage มักไปอยู่กับคนที่กล้าทำลายของตัวเอง ไม่ใช่คนที่กลัวจะทำลายของตัวเอง

ผลลัพธ์คือ ตลอดทศวรรษ 1980-90 Oracle กลายเป็น default database ของธนาคาร, รัฐบาล, telecom, สายการบิน, โรงพยาบาล ทั่วโลก ในไทยปี 2026 ระบบราชการและ core banking หลายเจ้ายังรัน Oracle อยู่เลย

ทำไม Relational ครองโลก 50 ปี#

ถึงตรงนี้ขอวกกลับมาคำถามใหญ่ครับ paper สั้นๆ ของ Codd ปี 1970 + product ของ Oracle ปี 1979 ทำไมยืนหยัดมาได้ถึงปี 2026 (ครึ่งศตวรรษเต็มๆ)? 3 เหตุผลหลัก

1. SQL ที่ standardize ได้#

ภาษา SQL กลายเป็น มาตรฐาน ANSI/ISO ตั้งแต่ปี 1986 แปลว่าเรียน SQL ครั้งเดียว ใช้ได้กับ database เกือบทุกตัว Oracle, MySQL, PostgreSQL, SQL Server, SQLite syntax หลักคล้ายกัน

ลองเทียบกับโลกที่ไม่มี standard ครับ ถ้าทุก database vendor มีภาษา query ของตัวเอง programmer ต้องเรียนใหม่ทุกครั้งที่เปลี่ยนงาน ตลาดแรงงานจะแคบ แต่พอมี SQL ก็มี ecosystem ของหนังสือ คอร์ส tool tutorial มหาศาล network effect ทำให้ relational ครองตลาดต่อ

2. Schema flexibility ที่พอดี#

Schema ใน relational เปลี่ยนได้ ทั้งเพิ่ม column สร้างตารางใหม่ เปลี่ยน data type โดยไม่ต้อง redesign ทั้งระบบเหมือน hierarchical แต่ก็ไม่ flexible เกินจน data เละ เหมือน schema-less ของ NoSQL ยุคหลัง (เรื่องนี้เก็บไว้คุยใน EP.04)

จุดสมดุลตรงนี้สำคัญ บังคับโครงสร้างเล็กน้อยพอให้ data clean แต่ยืดหยุ่นพอให้แก้ได้เมื่อ business เปลี่ยน นี่แหละเหตุผลที่ relational เหมาะกับ business application 90% ของโลก

3. Mathematical foundation ที่พิสูจน์ได้#

อันนี้เป็น advantage ที่คนนอกวงการมองข้ามบ่อย Relational model ของ Codd ตั้งอยู่บนทฤษฎี relational algebra + first-order logic ฐานคณิตศาสตร์ที่พิสูจน์ได้

แปลว่าอะไร? แปลว่า database optimizer “พิสูจน์” ได้ว่า query rewrite แบบ A กับแบบ B ให้ผลเหมือนกัน แล้วเลือกแบบที่เร็วกว่า นี่แหละเหตุผลที่ database engine สมัยใหม่ถึงเร็วขึ้นเรื่อยๆ โดยที่ programmer ไม่ต้องแก้ SQL engine ฉลาดขึ้นเอง เพราะมีฐาน math รองรับ

ของที่ตั้งบนคณิตศาสตร์ ปรับปรุงได้เป็นทศวรรษโดยไม่ต้องเปลี่ยน paradigm ของที่ตั้งบน “วิธีคิดของคนที่คิดออกในตอนนั้น” มักจะตันในไม่กี่ปี นี่คือเหตุผลที่ relational ยังอยู่หลัง 50 ปี ส่วน Network database ตายไปแล้ว

มุมผู้บริหาร: ทำไม mainframe banking + ระบบราชการไทย ปี 2026 ยังเต็มไปด้วย Oracle/IMS#

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

ถ้าคุณเข้าไปดูระบบหลังบ้านของธนาคารใหญ่ในไทย สำนักงานราชการ รัฐวิสาหกิจ โอกาสสูงมากที่ core system จะรันบน Oracle หรือ IMS บน mainframe ที่เริ่มใช้มาตั้งแต่ทศวรรษ 1980-90 ในขณะที่ทุกห้องประชุมพูดเรื่อง cloud, AI, NoSQL เบื้องหลังของระบบจริงๆ ยังเป็นของยุค Reagan

ทำไม? 3 เหตุผลที่ผู้บริหารต้องเข้าใจ

Switching cost สูงมหาศาล ระบบ core banking ที่รันมา 30 ปี เก็บ business logic ที่ผ่านการแก้ไขจาก programmer เป็นร้อยคน คนที่เข้าใจครบเกษียณไปหมดแล้ว การ migrate ออกไม่ใช่แค่ “copy data” มันคือการ “reverse engineer business logic 30 ปี” ที่ไม่มีคนเหลือเข้าใจ ค่าประเมินรวมความเสี่ยง บางเคสเป็นพันล้าน
ของเก่าเสถียรกว่าที่คิด Oracle ที่รันมา 30 ปีบน mainframe มี downtime ปีละไม่ถึงนาที ของใหม่ที่ vendor ให้คำสัญญาว่า “ดีกว่า เร็วกว่า ถูกกว่า” ยังไม่มีใครพิสูจน์ได้ว่าใช้ครบ 30 ปีแล้วเสถียรเท่ากัน ในธุรกิจที่ downtime 1 ชั่วโมง = เสียเงิน 100 ล้าน “ของพิสูจน์แล้ว” มีราคาในตัวมันเอง
Regulator + Audit framework ผูกอยู่กับของเดิม ธนาคารต้องตรวจระบบทุกปี auditor ที่เข้าใจ Oracle/IMS มีเยอะ ที่เข้าใจ NoSQL/cloud-native ในระดับลึกพอจะ audit ได้ยังน้อย การเปลี่ยน database = ต้องสร้าง audit framework ใหม่ทั้งชุด

สรุปมุมผู้บริหาร: ของใหม่ในวงการ database น่าตื่นเต้นก็จริง แต่ในธุรกิจที่มี regulatory pressure + downtime cost สูง + business logic legacy หนา “ของเก่าที่พิสูจน์แล้ว” มี value ที่ของใหม่ทดแทนยังไม่ได้ นี่ไม่ใช่ความขี้เกียจของ CIO มันคือการคำนวณ risk vs reward ที่สมเหตุสมผล ถ้าคุณเข้าไปคุยเรื่อง cloud migration กับธนาคาร แล้วเขาบอก “ขอเวลา 5-10 ปี” เขาไม่ได้ถ่วง เขากำลังคำนวณค่าของความเสี่ยงอยู่

ปิดบท + ข้ามไป EP.03#

EP.02 จบที่นี่ครับ ทศวรรษ 1960-70 คือทศวรรษที่ database เกิด และ ปฏิวัติ ในเวลาเดียวกัน

สิ่งที่เกิดในยุคนี้:

NASA Apollo เป็นโจทย์ที่บังคับให้ IBM สร้าง database จริงจังขึ้นมา → IMS ปี 1968
IMS + CODASYL เป็นยุคของ navigational database เร็วแต่แข็ง ยืดหยุ่นน้อย
Codd Paper 1970 เป็นจุดเปลี่ยน paradigm จาก navigational เป็น declarative
System R + SQL เกิดใน IBM Research แต่ไม่ปล่อยขาย เพราะกลัวกระทบ IMS
Oracle 1979 ฉวยจังหวะปล่อย relational database เชิงพาณิชย์ตัวแรก CIA เป็นลูกค้าแรก แล้วก็ครองโลก

บทเรียนใหญ่: Relational ชนะไม่ใช่เพราะ “ดีกว่า” แต่เพราะ เปลี่ยนวิธีคิดจาก “บอกวิธีไปหา” เป็น “บอกว่าต้องการอะไร” และเปลี่ยน paradigm ที่ตั้งอยู่บน ฐานคณิตศาสตร์ที่พิสูจน์ได้ ก็ทำให้ของยืนหยัดมาได้ครึ่งศตวรรษ

แต่… relational ที่เพิ่งเกิดในยุค 1970s ยังขาดอะไรอีกอย่างหนึ่งครับ สิ่งที่จะทำให้ ธนาคารกล้า bet ทุกบาทของลูกค้าไว้กับมัน

ลองคิดดู ถ้าลูกค้าโอนเงินจากบัญชี A ไปบัญชี B แล้วระบบ crash กลางทาง เงินตัดจาก A ไปแล้ว แต่ยังไม่เข้า B จะเกิดอะไรขึ้น? เงินหาย ลูกค้าโกรธ ธนาคารเสียชื่อเสียง ถูกฟ้อง เรื่องใหญ่

ในยุค 1970s relational database ยังไม่มีกลไกที่รับประกันว่าเรื่องนี้จะไม่เกิด การจะให้ธนาคารกล้าใช้ ต้องมี คุณสมบัติชุดหนึ่งที่รับประกัน “ความถูกต้องของ transaction” ถ้าไม่ครบ ต้องย้อนกลับให้เหมือนไม่เคยทำ

คุณสมบัติชุดนั้นมีชื่อว่า ACID และมันจะมาในยุค 1980s-90s EP.03 จะเล่าว่า ACID คืออะไร ทำไมมันบังคับให้ relational ครองเฉพาะตลาด enterprise mission-critical และทำไมการประกัน “ความถูกต้อง” นี้ ภายหลังจะกลายเป็น ข้อจำกัดที่ NoSQL ในยุค 2000s ต้องหาทางหนี

→ EP.03 — ยุค 1980s-90s: ACID + Enterprise Backbone (เร็วๆ นี้)