ชุมชนเทคโนโลยีกำลังมีการอภิปรายอย่างร้อนแรงเกี่ยวกับว่าฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิมยังคงเป็นตัวเลือกที่เหมาะสมสำหรับแอปพลิเคชันสมัยใหม่ที่ต้องจัดการกับโครงสร้างข้อมูลที่ซับซ้อนและหลากหลายหรือไม่ การสนทนานี้เริ่มต้นจากความท้าทายในการจัดเก็บข้อมูลแบบ polymorphic - ข้อมูลที่สามารถมีรูปแบบที่แตกต่างกันขึ้นอยู่กับสถานการณ์ เช่น วิธีการชำระเงินที่อาจเป็นได้ทั้งบัตรเครดิตหรือบัญชีธนาคาร
แนวทางดั้งเดิมเริ่มแสดงอายุ
นักพัฒนาต้องดิ้นรนมานานกับการใส่ข้อมูลที่ซับซ้อนลงในโครงสร้างตารางที่เข้มงวดของฐานข้อมูลเชิงสัมพันธ์ แนวทางมาตรฐานรวมถึงการสร้างตารางกว้างที่มีคอลัมน์ที่สามารถเป็น null ได้มากมาย การแยกข้อมูลออกเป็นหลายตารางที่เกี่ยวข้องกัน หรือการใช้ความสัมพันธ์ foreign key แต่ละวิธีมาพร้อมกับการแลกเปลี่ยนระหว่างประสิทธิภาพการ query ความสมบูรณ์ของข้อมูล และความซับซ้อนในการบำรุงรักษา
นักพัฒนาหลายคนพบว่าโซลูชันแบบดั้งเดิมเหล่านี้ยุ่งยากมากขึ้นเรื่อยๆ ความจำเป็นในการเขียนกฎการตรวจสอบที่ซับซ้อน จัดการกับค่า null จำนวนมาก และจัดการความสัมพันธ์ที่ซับซ้อนระหว่างตารางต่างๆ สร้างสิ่งที่บางคนเรียกว่าความซับซ้อนโดยบังเอิญ - ปัญหาที่เกิดขึ้นเพราะเครื่องมือที่เราใช้ ไม่ใช่เพราะความต้องการทางธุรกิจที่แท้จริง
แนวทางฐานข้อมูลห้าแบบสำหรับข้อมูล Polymorphic:
- ตารางเดียวพร้อมฟิลด์ที่สามารถเป็น Null ได้ - ง่ายแต่สร้างค่า null จำนวนมาก
- Foreign Keys จาก Parent ไป Child - การทำ normalization ที่ดีกว่าแต่ query ซับซ้อน
- Tagged Union ของ Foreign Keys - ยืดหยุ่นแต่ต้องการการตรวจสอบความถูกต้องที่ซับซ้อน
- Foreign Keys จาก Child ไป Parent - ความสัมพันธ์ที่ชัดเจนแต่มีความท้าทายในการตรวจสอบความถูกต้อง
- คอลัมน์ JSON - การประนีประนอมแบบสมัยใหม่ที่มีความยืดหยุ่นในตัว
ชุมชนผลักดันให้ใช้ทางเลือกสมัยใหม่
การอภิปรายได้เผยให้เห็นความคิดเห็นที่รุนแรงเกี่ยวกับการละทิ้งฐานข้อมูลแบบดั้งเดิมโดยสิ้นเชิง นักพัฒนาบางคนสนับสนุนโซลูชัน NoSQL เช่น MongoDB ที่จัดการกับโครงสร้างข้อมูลที่หลากหลายได้อย่างเป็นธรรมชาติโดยไม่ต้องใช้กิมนาสติกสคีมาที่ซับซ้อน คนอื่นๆ ชี้ไปที่เทคโนโลยีฐานข้อมูลใหม่ๆ ที่ยอมรับแนวทางการสร้างแบบจำลองข้อมูลที่แตกต่างกัน
ณ จุดหนึ่ง เราต้องตระหนักว่าเรากำลังใช้ primitives ที่ผิดประเภทในการสร้างระบบกระจายในปัจจุบัน เห็นได้ชัดว่า OO และ RDBMS จะไม่พาเราออกจากหลุมแอสฟัลต์ได้
ฐานข้อมูล Entity-Attribute-Value (EAV) เช่น Datomic และ XTDB กำลังได้รับความสนใจในด้านความยืดหยุ่นในการจัดการข้อมูล polymorphic ระบบเหล่านี้ถือว่าแอตทริบิวต์แต่ละตัวเป็นหน่วยสร้างพื้นฐาน แทนที่จะบังคับให้ทุกอย่างเข้าไปในโครงสร้างตารางที่กำหนดไว้ล่วงหน้า
เทคโนโลยีฐานข้อมูลทางเลือกที่กล่าวถึง:
- NoSQL: MongoDB สำหรับการจัดเก็บข้อมูลแบบเอกสาร
- ฐานข้อมูล EAV: Datomic, XTDB สำหรับการสร้างแบบจำลอง entity-attribute-value
- ฐานข้อมูลกราฟ: EdgeDB ที่มีการรองรับการสืบค้นแบบ polymorphic โดยธรรมชาติ
- แพลตฟอร์มแบบกระจาย: Rama สำหรับการจัดการข้อมูลและการคำนวณแบบรวมศูนย์
JSON โผล่มาเป็นจุดกึ่งกลางที่ปฏิบัติได้
สำหรับทีมที่ยังไม่พร้อมที่จะละทิ้งโครงสร้างพื้นฐานฐานข้อมูลที่มีอยู่ คอลัมน์ JSON เสนอโซลูชันแบบประนีประนอม ฐานข้อมูลสมัยใหม่เช่น PostgreSQL และ MySQL ตอนนี้ให้การสนับสนุน JSON ที่แข็งแกร่งพร้อมความสามารถในการสร้างดัชนีและการตรวจสอบ แนวทางนี้ช่วยให้นักพัฒนาสามารถจัดเก็บโครงสร้างข้อมูลที่ซับซ้อนและหลากหลายในขณะที่ยังคงรักษาประโยชน์บางอย่างของฐานข้อมูลเชิงสัมพันธ์ไว้
อย่างไรก็ตาม ชุมชนยังคงแบ่งแยกในแนวทางนี้ แม้ว่าคอลัมน์ JSON จะแก้ปัญหาเร่งด่วนในการจัดเก็บข้อมูล polymorphic แต่ก็อาจทำให้การ query ซับซ้อนมากขึ้นและอาจส่งผลต่อประสิทธิภาพในบางกรณีการใช้งาน
การค้นหา Primitives ที่ดีกว่า
การสนทนาที่กว้างขึ้นเผยให้เห็นคำถามพื้นฐานเกี่ยวกับว่าเทคโนโลジีฐานข้อมูลปัจจุบันเพียงพอสำหรับระบบกระจายสมัยใหม่หรือไม่ นักพัฒนาบางคนโต้แย้งว่าโซลูชันที่แท้จริงอยู่ในแพลตฟอร์มที่จัดการทั้งการจัดเก็บข้อมูลและการคำนวณร่วมกัน แทนที่จะถือว่าเป็นเรื่องแยกกัน
การเปลี่ยนแปลงในการคิดนี้บ่งชี้ว่ากระบวนการเลือกฐานข้อมูลควรมุ่งเน้นไปที่การเลือกเครื่องมือที่สอดคล้องกับรูปแบบข้อมูลและความต้องการในการเข้าถึงของแอปพลิเคชันอย่างเป็นธรรมชาติ มากกว่าการบังคับให้แบบจำลองข้อมูลที่มีอยู่เข้ากับโครงสร้างแบบดั้งเดิม
การถกเถียงนี้เน้นย้ำถึงช่วงเปลี่ยนผ่านที่สำคัญในการพัฒนาซอฟต์แวร์ ที่ทีมต้องสร้างสมดุลระหว่างความมั่นคงและความคุ้นเคยของเทคโนโลยีที่ก่อตั้งขึ้นแล้ว กับประโยชน์ที่อาจได้รับจากแนวทางใหม่ๆ ที่ออกแบบมาสำหรับความต้องการข้อมูลที่ซับซ้อนในปัจจุบัน