คอลัมน์ Featured ที่เคยทำให้เราเสียเงินฟรี และการแก้ปัญหาด้วย Schema ใหม่
บทเรียนจากการออกแบบฐานข้อมูลระบบไดเรกทอรีโรงเรียนเด็กพิเศษในสหรัฐอเมริกา เมื่อคอลัมน์เดียวทำพิษเพราะความต้องการของลูกค้าเป็นแบบท้องถิ่นแต่ฐานข้อมูลดันเป็นแบบโกลบอล
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ระบบไดเรกทอรีโรงเรียนและศูนย์บำบัด ABA ในสหรัฐฯ ใช้ฐานข้อมูลจำหน่ายพื้นที่โปรโมท
- ปัญหาเริ่มต้นจากคอลัมน์ integer ตัวเดียวชื่อ featured_priority ทำให้ธุรกิจดันติดอันดับทุกเมือง
- การแก้ปัญหาทำได้โดยเปลี่ยนมาใช้ตาราง coverage สำหรับจัดการพื้นที่ให้บริการเฉพาะจุด
- บทเรียนสำคัญคือสถานะการโปรโมทควรผูกกับความสัมพันธ์ของสถานที่ ไม่ใช่ตัวธุรกิจหลัก
ทีมนักพัฒนาซอฟต์แวร์ระบบไดเรกทอรีสำหรับโรงเรียนเด็กพิเศษและผู้ให้บริการบำบัด ABA ในสหรัฐอเมริกา ได้แชร์ประสบการณ์การออกแบบฐานข้อมูลที่เคยผิดพลาดจนทำให้บริษัทสูญเสียรายได้ โดยระบบอนุญาตให้ผู้ให้บริการจ่ายเงินเพื่อโปรโมทตำแหน่งของตนเองในหน้าค้นหาของพ่อแม่ผู้ปกครอง ซึ่งในเวอร์ชันแรกสุด ทีมงานเลือกใช้แนวทางที่ง่ายที่สุดด้วยการเพิ่มคอลัมน์ชนิด integer เพียงหนึ่งคอลัมน์ลงไปในตาราง listings เท่านั้น
โครงสร้างฐานข้อมูลเดิมใช้คำสั่งสร้างตารางดังนี้:
create table listings (
id uuid primary key,
name text,
city text,
state text,
featured_priority int default 0 -- higher sorts first
);และคำสั่งคิวรี (Resolver) ในหน้าแสดงผลรายเมือง:
select * from listings
where city = $1 and state = $2
order by featured_priority desc, name asc;แนวทางนี้สามารถพัฒนาและส่งมอบงานได้ภายในช่วงบ่ายวันเดียว และใช้งานได้ปกติดีประมาณหนึ่งปี จนกระทั่งพวกเขาพบว่าโครงสร้างข้อมูลแบบนี้กำลังทำให้บริษัทเสียเงินฟรี เพราะแนวคิดเรื่องความโดดเด่นหรือ Featured ไม่ใช่คุณสมบัติโดยตรงของตัวธุรกิจ แต่เป็นคุณสมบัติของความสัมพันธ์ระหว่างธุรกิจกับพื้นที่นั้นๆ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อผู้ให้บริการรายหนึ่งมีคลินิกครอบคลุมพื้นที่สี่สิบเมืองในสามรัฐ พวกเขาไม่ได้ต้องการซื้อพื้นที่ทั้งสี่สิบเมือง แต่ต้องการแค่เขตมหานครที่สำนักงานตั้งอยู่ หรืออาจจะสักสองเขตมหานครเท่านั้น แต่เนื่องจากคอลัมน์ featured_priority ไปฝังอยู่บนแถวของรายชื่อธุรกิจ (listing row) ทันทีที่ระบบตั้งค่าสถานะดังกล่าว ผู้ให้บริการรายนั้นจึงกลายเป็นผู้มีอันดับเหนือกว่าคนอื่นในทั้งสี่สิบเมืองโดยอัตโนมัติ กลายเป็นว่าคอลัมน์มีลักษณะเป็นแบบโกลบอล แต่สินค้าที่นำเสนอขายเป็นแบบท้องถิ่น (local)
การวิเคราะห์เชิงสถาปัตยกรรมข้อมูล: ปัญหานี้สะท้อนให้เห็นข้อผิดพลาดคลาสสิกในการออกแบบฐานข้อมูลที่เรียกว่า Entity-Attribute Mismatch เมื่อคุณนำคุณสมบัติที่มีขอบเขตเฉพาะเจาะจง (Scope-specific attribute) ไปแปะไว้กับตารางหลักที่มีขอบเขตใหญ่กว่า ระบบจะไม่สามารถรองรับเงื่อนไขทางธุรกิจที่ซับซ้อนขึ้นได้ในอนาคต เช่น การต้องการโปรโมทธุรกิจในเมืองเดนเวอร์แต่ให้แสดงผลเป็นปกติในเมืองโบลเดอร์ ซึ่งแนวทางการแก้ไขที่ถูกต้องคือการสร้างตารางเชื่อมโยงแยกต่างหากเพื่อกำหนดขอบเขตความสัมพันธ์แบบหลายต่อหลาย (Many-to-Many Relationship)
ในบทความยังได้ระบุถึงปัญหาสำคัญอีกประเด็นเกี่ยวกับการเขียนคำสั่งจัดลำดับ (Rank override) ที่เข้าใจผิดคิดว่าเป็นตำแหน่งตายตัว แต่ความจริงแล้วเป็นเพียงอินพุตสำหรับกระบวนการเรียงลำดับ (Sorting) เท่านั้น ทำให้การจะดันใครไปอยู่อันดับสองจำเป็นต้องใช้วิธีปักหมุดรายอื่นขึ้นไปอยู่อันดับหนึ่งแทน รวมถึงปัญหาเรื่องพื้นที่บริการ (Service area coverage) ที่ตอบคำถามว่าธุรกิจอาจจะแสดงที่ไหนได้บ้าง แต่ไม่สามารถตอบคำถามว่าสถานที่นั้นมีอยู่จริงหรือไม่ จนนำไปสู่ปัญหาหน้าเว็บแสดงผลผิดพลาด 404 สำหรับเมืองที่ไม่มีรายชื่อธุรกิจตั้งอยู่จริงๆ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น