ฉากเปิด — เช้าวันจันทร์ที่ Excel ของบริษัทพังต่อหน้าทุกคน#

ลองนึกภาพออฟฟิศบริษัทขนาดกลางในกรุงเทพครับ พนักงานสัก 50 คน ขายของออนไลน์ + มีหน้าร้าน ลูกค้าในระบบประมาณ 80,000 ราย ทั้งหมดเก็บอยู่ในไฟล์เดียว ชื่อว่า customer_list_FINAL_v7.xlsx วางอยู่บน shared drive ของบริษัท ทุกคนในแผนก sales เปิดได้ ทุกคนแก้ได้ ทุกคนเซฟทับได้

เช้าวันจันทร์หนึ่ง น้องในทีม sales ชื่อนุ้ย เปิดไฟล์ขึ้นมาตอน 9 โมง อัปเดตเบอร์โทรลูกค้าใหม่ 30 ราย แล้วกด Save

พอดีกัน พี่เอ๋อีกฝั่งของออฟฟิศก็เปิดไฟล์เดียวกันไว้ตั้งแต่ 8.45 น. กำลังกรอกที่อยู่ลูกค้าอีก 50 ราย แล้วกด Save ตอน 10 โมงครึ่ง

Excel เด้ง dialog ขึ้นมา ปุ่ม “Save a Copy” สีเทา พี่เอ๋ไม่อ่าน กด OK ผ่านๆ ปรากฏว่างานของน้องนุ้ย 30 ราย หายเรียบ

บ่ายวันเดียวกัน ฝ่ายบัญชีโทรมาถามว่า “ลูกค้า ABC Trading ที่อยู่ตรงไหน” ฝ่าย sales ตอบ “เพิ่งอัปเดตเช้านี้นะพี่ อยู่ในไฟล์” ฝ่ายบัญชีบอก “ในไฟล์ที่บัญชีถือไว้คือที่อยู่เก่า” ฝ่าย marketing เสริม “งง ในไฟล์ที่ marketing copy ออกไปทำแคมเปญเมื่อวานคือที่อยู่อีกแบบ”

อ้าว ออฟฟิศนี้ไม่ได้มี customer list 1 ไฟล์ครับ มันมี 5 ไฟล์ที่ทุกคนคิดว่าเป็นไฟล์เดียวกัน เพราะแต่ละแผนก save as ออกไปทำงานของตัวเอง แล้วไม่เคย sync กลับ

ย้ำก่อนว่านี่ไม่ใช่บริษัทที่ผมรู้จักนะครับ เป็น scenario สมมติ แต่ถ้าใครเคยทำงานในบริษัทไทยขนาดกลางที่ยังพึ่ง shared Excel อยู่ น่าจะมีภาพคล้ายๆ กันในหัว และนี่แหละคือฉากที่จะตอบคำถามใหญ่ของ EP.01 ทำไมโลกถึงต้องคิด database ขึ้นมาตั้งแต่แรก?

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

EP นี้จะพาเดินทางจากกระดาษ → Excel → ปัญหา 4 ข้อที่บังคับให้โลกประดิษฐ์ database ขึ้นมา ไม่มี SQL ไม่มี schema ไม่มีศัพท์เทคนิค เน้นทำความเข้าใจว่า database เป็นคำตอบของปัญหามนุษย์ ไม่ใช่เครื่องมือเทคโนโลยีลึกลับ

โลกก่อนมี database — กระดาษ, ตู้แฟ้ม, แล้วก็ Excel#

ก่อนจะเข้าใจว่า database คืออะไร ต้องย้อนไปดูก่อนว่า “ก่อนมี database” คนเก็บข้อมูลกันยังไง

ย้อนไปยุคก่อนคอมพิวเตอร์เข้ามาในออฟฟิศ ทุกบริษัทใช้ ledger กระดาษ ledger คือสมุดบัญชีเล่มใหญ่ๆ ที่นั่งเขียนด้วยมือ ธนาคารใช้ ledger เก็บยอดเงินของลูกค้า โรงงานใช้เก็บสต๊อก ห้างใช้เก็บใบสั่งซื้อ แต่ละหน้ามีตาราง มีคอลัมน์ มีลายมือคนจดที่บางทีอ่านไม่ออก ถ้าใครเขียนผิดก็ขีดฆ่าแล้วเซ็นชื่อกำกับ

ปัญหาของ ledger กระดาษเห็นชัดเลยครับ ถ้ามีคน 5 คนต้องดูเล่มเดียวกันพร้อมกัน ทำไม่ได้ ถ้าจะหาว่าลูกค้าคนหนึ่งซื้ออะไรบ้างเมื่อปีก่อน ต้องเปิดทีละหน้า ถ้าน้ำท่วมหรือไฟไหม้ จบ

ของจริงในประวัติศาสตร์ ปี 1890 รัฐบาลอเมริกาใช้เวลา 8 ปี นับสำมะโนประชากรครั้งหนึ่งด้วยกระดาษ นั่นแหละคือเหตุผลที่ Herman Hollerith ประดิษฐ์เครื่องอ่านบัตรเจาะรู (ซึ่งภายหลังกลายเป็นบริษัทชื่อ IBM) เพื่อให้นับเสร็จใน 1 ปีแทน

พอคอมพิวเตอร์เข้าออฟฟิศปลายยุค 70s ก็มีของใหม่มาแทน ledger ชื่อ flat file หน้าตามันคือไฟล์ตัวอักษรธรรมดาที่เก็บข้อมูลทีละบรรทัด คั่นด้วยเครื่องหมายอะไรสักอย่าง (, หรือ | หรือ tab) ลองนึกภาพไฟล์แบบนี้

1
1001,สมชาย ใจดี,089-xxx,กรุงเทพ
2
1002,สมหญิง สุขใจ,082-xxx,เชียงใหม่
3
1003,วิชัย รักงาน,090-xxx,ภูเก็ต

แต่ละบรรทัด = ลูกค้า 1 คน เครื่องคำนวณรายงานได้เร็วกว่ากระดาษเป็นพันเท่า แต่ flat file มีปัญหาเดิมของ ledger เกือบทั้งหมด ถ้ามี 2 โปรแกรมพยายามเขียนพร้อมกัน ข้อมูลพัง ถ้าจะหาลูกค้า 1 คน ต้องอ่านทีละบรรทัดจากต้นไฟล์ ถ้าจะแก้คอลัมน์ใหม่ ต้องเขียนใหม่ทั้งไฟล์

แล้วก็เกิดยุคทอง ยุคของ spreadsheet Lotus 1-2-3 ปี 1983, Excel ปี 1985 ของที่เคยต้องเขียนโปรแกรมเป็นเดือน ตอนนี้เลขาในออฟฟิศกดสร้างตารางได้ใน 5 นาที Excel เปลี่ยนวงการเหมือนสายฟ้าฟาด ทุกออฟฟิศทั่วโลกมี Excel แล้วทุกอย่างที่เคยเป็น “ข้อมูลของบริษัท” ก็ค่อยๆ ย้ายเข้า Excel ทั้งหมด

ตัดมาปี 2026 เกือบ 40 ปีหลัง Excel ออก บริษัทไทยขนาดกลางจำนวนมาก ยังบริหารธุรกิจหลักของตัวเองบน Excel + Google Sheets customer list อยู่ใน Excel สต๊อกของอยู่ใน Excel payroll อยู่ใน Excel KPI ของพนักงานอยู่ใน Excel มี shared drive 1 ตัวที่เก็บไฟล์ Excel หลายร้อยไฟล์ บางไฟล์เปิดไม่ขึ้นเพราะใหญ่เกิน บางไฟล์มีชื่อ final_FINAL_real_v3_use_this_one.xlsx 555+

ทำไมถึงเป็นแบบนี้? เพราะ Excel เริ่มต้นง่ายมาก เปิดมาพิมพ์ได้เลย ไม่ต้องเรียน ไม่ต้องจ้าง dev เจ้าของกิจการคิดว่า “เก็บใน Excel ก็พอแล้ว เหลือเฟือ” แล้วบริษัทก็โต ลูกค้าจาก 100 → 1,000 → 80,000 พนักงานจาก 5 → 20 → 50 ไฟล์ Excel เดิมก็โตตาม ปัญหาก็เริ่มผุดขึ้นทีละข้อ จนถึงจุดที่ทุกคนรู้สึกว่า “มันต้องมีวิธีที่ดีกว่านี้แน่ๆ”

วิธีที่ดีกว่านั้นแหละครับ โลกเรียกมันว่า database แต่ก่อนจะคุยว่า database คืออะไร ต้องเข้าใจก่อนว่าปัญหาที่มันมาแก้คืออะไร

4 ปัญหาที่ทำให้โลกต้องคิด database ขึ้นมา#

ทุกครั้งที่มนุษย์พยายามเก็บข้อมูลร่วมกันแบบ “ใครๆ ก็เข้าถึงได้” ไม่ว่าจะเก็บในกระดาษ ใน flat file หรือใน Excel มี 4 ปัญหานี้ผุดขึ้นมาเสมอ และ database ทุกตัวในโลกเกิดมาเพื่อแก้ปัญหา 4 ข้อนี้

Database = เครื่องมือที่แก้ทั้ง 4 ปัญหา#

ทีนี้พอเรารู้ปัญหาแล้ว มาดูว่า database มันแก้ยังไง ตรงนี้จะแค่เกริ่นภาพรวมนะครับ กลไกแต่ละตัวจะเจาะลึกใน EPs ถัดไป

1. Single Source of Truth — แก้ Redundancy

แทนที่ลูกค้า ABC Trading จะอยู่ใน 5 ไฟล์ ใน database ลูกค้าจะอยู่ที่เดียว ทุกแผนกที่อยากรู้เรื่องลูกค้านี้ “ดึงจากที่เดียวกัน” ฝ่าย sales ดึง ฝ่าย accounting ดึง ฝ่าย marketing ดึง ได้ข้อมูลเดียวกันเสมอ คอนเซ็ปต์นี้เรียกว่า single source of truth มีเวอร์ชันเดียว ไม่มีเวอร์ชันแข่งกัน

2. Constraint + Validation — แก้ Integrity

database บังคับ “กฎ” ตอนเขียนข้อมูลเข้ามา เช่น เบอร์โทรต้องเป็นตัวเลข 9-10 หลัก, อีเมลต้องมี @, รหัสลูกค้าต้องไม่ซ้ำกับคนอื่น, ที่อยู่ของลูกค้ามีได้ที่อยู่เดียวเป็น “ที่อยู่หลัก” ใครพยายามเขียนข้อมูลที่ผิดกฎ database ปฏิเสธทันที ผิดกันที่ entry ไม่ใช่ปล่อยให้ผิดข้ามแผนกเหมือน Excel

3. Locking + Transaction — แก้ Concurrency

ตอนน้องนุ้ยกำลังแก้ลูกค้า ABC Trading database จะ “ล็อก” ข้อมูลของลูกค้าคนนั้นไว้ชั่วคราว ถ้าพี่เอ๋พยายามแก้ในเวลาเดียวกัน database บอก “รอก่อน คนอื่นกำลังแก้อยู่” หรือไม่ก็ใช้กลไกที่ซับซ้อนกว่าที่เรียกว่า transaction ที่รับประกันว่า “งานทั้งก้อน” สำเร็จทั้งหมดหรือล้มเหลวทั้งหมด ไม่มีสภาพ “ครึ่งๆ กลางๆ”

(เรื่องนี้สำคัญมากสำหรับระบบธนาคาร เดี๋ยวเจาะลึกใน EP.08 — Transaction + Concurrency Control)

4. Index — แก้ Search

แทนที่จะอ่านทีละแถวจากต้นไฟล์ database สร้าง “index” คล้ายดัชนีท้ายเล่มหนังสือ ที่บอกว่า “ลูกค้าชื่อสมชาย เริ่มที่ตำแหน่ง X” “เบอร์ 089-xxx อยู่ที่ตำแหน่ง Y” การหาเลยเปลี่ยนจาก “เดินดูทุกชั้นในห้องสมุด” → “เปิดดูบัตรรายการแล้วเดินไปที่ชั้นที่ระบุ”

ผลลัพธ์คือ query ที่ใน Excel ใช้เวลา 3 นาที ใน database ใช้เวลา เป็น milli-second (เร็วเป็นพันเท่า) และไม่ว่าข้อมูลจะมี 1,000 แถวหรือ 100 ล้านแถว index ก็ทำให้ search เร็วในระดับเดียวกัน

(กลไก index จะเจาะลึกใน EP.07 — Index + Query Optimization)

ตรงนี้ผมไม่อยากให้คุณจำคำศัพท์ครับ แค่ให้เก็บไอเดียไปว่า database คือเครื่องมือที่ออกแบบมาเพื่อแก้ปัญหา 4 ข้อนี้พร้อมกัน ไม่ใช่แค่ “ที่เก็บข้อมูล” Excel ก็เก็บข้อมูล กระดาษก็เก็บข้อมูล แต่ database คือที่เก็บข้อมูล + กลไกที่บังคับให้ข้อมูลเชื่อถือได้

ทำไม “Excel = database” คือความเข้าใจผิดที่ scale ไม่ได้#

ถึงตรงนี้ผู้บริหารบางคนอาจจะคิดว่า “เออ แต่ Excel ก็เก็บข้อมูลได้นี่ เก็บเป็น sheet ได้ มี formula ได้ มี filter ได้ Google Sheets ก็ collaborative ด้วย ทำไมต้องใช้ database?”

คำตอบคือ Excel/Google Sheets ทำได้ “บางอย่าง” ของ database แต่ขาดคุณสมบัติหลักอย่างน้อย 3 ข้อที่ทำให้มัน scale ไม่ได้

1. ไม่มี constraint enforcement จริงๆ

ลองพยายามทำใน Excel ดูครับ บังคับว่าคอลัมน์ “เบอร์โทร” ต้องเป็น 9-10 หลักเท่านั้น และต้องไม่ซ้ำกับลูกค้าคนอื่น Excel มี data validation นิดหน่อย แต่ใครก็ลบ validation ออกได้ เผลอ paste ข้อมูลที่มี format ผิดเข้ามา validation ไม่ทำงานในหลายเคส ถ้าจะให้กฎแน่นจริง ต้องเขียน VBA macro ซึ่งไม่มีใครในออฟฟิศบำรุงรักษาเป็น

2. ไม่มี true concurrency control

Google Sheets ดีขึ้นกว่า Excel เยอะตรงที่ collaborative ได้ หลายคนแก้พร้อมกันโดยไม่เซฟทับ แต่ “เห็นการแก้ของกันและกัน” ≠ “transaction control” ถ้า 2 คนพร้อมกันลด stock จาก 1 → 0 Google Sheets ไม่ได้ป้องกัน ทั้ง 2 เซลล์เห็น 1 ลด 1 = 0 พร้อมกัน ลูกค้า 2 คนได้ confirm ทั้งคู่ ของจริงมีชิ้นเดียว

3. มี hard limit ที่ขนาด

Excel: เปิดไฟล์ 1 ล้านแถวแล้วอืดจน unusable Google Sheets: hard limit ที่ประมาณ 10 ล้าน cell ต่อ file ถ้าธุรกิจคุณมีออเดอร์เดือนละ 10,000 ปีละ 120,000 5 ปีก็เริ่มชน limit ธุรกิจที่โตจริงๆ ทะลุ Excel ใน 2-3 ปี

แล้วทำไม power user ของไทยติด Excel แล้วย้ายไป proper database ยาก? เพราะ Excel ไม่ได้แค่เก็บข้อมูล มันเก็บ ขั้นตอนการคิดของคนทำงาน ไว้ด้วย สูตร VLOOKUP ที่ป้าวางไว้ใน column G สูตร pivot table ที่พี่ทำไว้ใน sheet 3 macro ที่น้องเขียนไว้ตอนทำ thesis ทุกอย่างอยู่ใน file เดียว การย้ายไป database ไม่ใช่แค่ “ย้ายข้อมูล” มันคือการ แยกข้อมูลออกจาก logic แล้วเขียน logic ใหม่ในเครื่องมืออื่น (เช่น BI tool หรือ web application)

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

มุมผู้บริหาร — 3 signal ที่บอกว่า “ถึงเวลาเลิกใช้ Excel แล้ว”#

ถ้าคุณเป็นเจ้าของกิจการที่ยังบริหารหลายอย่างบน Excel + Google Sheets ผมไม่ได้บอกว่าให้รีบทิ้งทั้งหมดวันนี้นะครับ Excel ยังเหมาะกับงานหลายแบบ ทั้ง financial modeling, ad-hoc analysis, รายงานครั้งเดียว แต่ถ้าธุรกิจของคุณเข้า signal ข้อใดข้อหนึ่งข้างล่างนี้ แปลว่าถึงเวลาแล้วที่ต้องเริ่มคิดเรื่องการย้ายข้อมูลหลักไป database

Signal 1: มีคน 3 คนขึ้นไปต้องแก้ไฟล์เดียวกันเป็นประจำ

ทันทีที่มีมากกว่า 2 คนต้องแก้ข้อมูลก้อนเดียวกัน ปัญหา concurrency จะเริ่มปรากฏ คุณจะเริ่มได้ยินคำว่า “งานหายไปครึ่งวัน” หรือ “พี่ใช้ไฟล์เก่าอยู่หรือเปล่า” ถ้าได้ยินมากกว่าเดือนละครั้ง แปลว่า Excel กำลังกินเวลาทีมคุณอยู่เงียบๆ

Signal 2: ข้อมูลของคุณเกิน 100,000 row

ที่ระดับนี้ Excel เริ่มอืด การเปิดไฟล์ใช้เวลาเป็นนาที ทีมเริ่ม split ข้อมูลออกเป็น “ลูกค้า_active.xlsx” + “ลูกค้า_inactive.xlsx” + “ลูกค้า_เก่า.xlsx” นั่นแหละอาการของ Excel ที่ scale ถึงเพดานแล้ว ทุกครั้งที่ split ปัญหา redundancy + integrity ก็เพิ่มขึ้นตาม

Signal 3: มี report ที่ต้องดึงจาก 3+ sheet มา join กัน

ถ้าทีมการเงินของคุณต้องเปิด 3 ไฟล์ทุกเดือน → ทำ VLOOKUP เชื่อมข้อมูลกัน → copy ลง pivot table → export เป็น report แปลว่าคุณกำลังทำ “manual database” บน Excel อยู่ ถ้าเปลี่ยนไปใช้ database จริงๆ + BI tool งาน 2 วันต่อเดือนนี้จะกลายเป็น dashboard ที่ refresh เองทุกชั่วโมง

แล้วถ้าไม่ migrate คุณเสียอะไรบ้าง? ลองคำนวณคร่าวๆ ดูครับ

• เวลาคน: ทีม sales เสียเวลาเฉลี่ย 30 นาที/วัน หา/แก้/ส่งไฟล์ Excel × 5 คน × 250 วัน/ปี = 625 ชั่วโมง/ปี = เกือบ 4 เดือนของพนักงาน 1 คน หายไปกับการจัดการไฟล์
• decision ผิด: ถ้า CEO ตัดสินใจขยายสาขาจาก report ที่ตัวเลขผิด ผลกระทบเป็นล้าน
• ลูกค้าไม่ happy: call center หาข้อมูลลูกค้าช้า → รีวิวลบ → ลูกค้าหาย → ยอดขายตก
• ทีมหมดไฟ: การทำงานกับ Excel ที่ค้าง + งานหายเป็นประจำ = พนักงานเก่งลาออก

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

ปิดบท — database ไม่ใช่เทคโนโลยี มันคือคำตอบของปัญหามนุษย์#

เรามาไกลพอสมควรแล้วครับสำหรับ EP เปิดซีรีส์ ถ้าจะสรุปทั้งบทเป็นประโยคเดียวคือ database ไม่ใช่เครื่องมือเทคโนโลยีลึกลับที่นักพัฒนาคิดขึ้นมาให้ดูเท่ มันคือคำตอบของปัญหา 4 อย่างที่มนุษย์เจอทุกครั้งที่พยายามเก็บข้อมูลร่วมกัน — Redundancy, Integrity, Concurrency, Search

ตั้งแต่ ledger กระดาษยุคก่อน computer จนถึง spreadsheet ของยุคปัจจุบัน ทุกครั้งที่ข้อมูลในธุรกิจโตเกิน “ขนาดที่คนคนเดียวจัดการไหว” ปัญหา 4 ข้อนี้จะผุดขึ้นเสมอ database คือเครื่องมือที่วงการ IT ใช้เวลาประดิษฐ์มา 60 ปี เพื่อแก้มันอย่างเป็นระบบ

ตอนนี้เรารู้แล้วว่า database แก้ปัญหาอะไร แต่ database เกิดมายังไง? ในประวัติศาสตร์มันไม่ได้เกิดมาในรูปแบบที่เราคุ้นเคยทันที

ก่อนจะเป็น Oracle, MySQL, PostgreSQL ที่ทุกคนรู้จักในวันนี้ database ผ่าน 4 ยุคใหญ่ ยุคแรกคือยุค Hierarchical + Network ของปี 1960s ที่ NASA Apollo ใช้ส่งคนไปดวงจันทร์ ยุคที่สองคือ Relational Revolution ที่ Edgar Codd นักวิจัยของ IBM โยน paper ทิ้งไว้ปี 1970 แล้วทำให้ตารางกับ SQL ครองวงการไปอีก 50 ปี

EP.02 จะพากลับไปที่จุดเริ่มต้นจริงๆ โลกของ database ที่ออกแบบมาเหมือนต้นไม้กลับหัว, ทำไมมันเหมาะกับ NASA แต่ไม่เหมาะกับธุรกิจ, และทำไม paper สั้นๆ ของชายคนหนึ่งใน IBM ปี 1970 ถึงเปลี่ยนวงการไปทั้งวงการ

→ EP.02 — ยุค 1960s-70s: Hierarchical → Relational Revolution (เร็วๆ นี้)