ข้อมูลลูกค้าซ้ำใน Web App ควรลบหรือรวม? ออกแบบ Identity Rule และ Merge Record อย่างไร

ชื่อเหมือน เบอร์เหมือน ไม่ได้แปลว่าเป็นลูกค้าคนเดียวเสมอไป

พนักงานฝ่ายขายเปิดระบบหลังบ้านแล้วพบลูกค้าชื่อคล้ายกันสามรายการ เบอร์โทรตรงกันสองแถว และมีคำสั่งซื้อกระจายอยู่คนละ Record ผู้จัดการอยากให้ลบข้อมูลซ้ำเพื่อให้ Dashboard นับจำนวนลูกค้าไม่เกินจริง แต่เมื่อถามว่าแถวไหนควรเป็นตัวหลัก ไม่มีใครตอบได้ เพราะไม่รู้ว่าระบบใช้รหัสอะไรแทนตัวตนจริง

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

คำตอบสั้นคืออย่าลบหรือ Merge Record ทันทีเพียงเพราะชื่อ อีเมล หรือเบอร์โทรเหมือนกัน ให้กำหนด Identity Rule, ตรวจความสัมพันธ์ของข้อมูล, วางสิทธิ์ผู้อนุมัติ และเตรียมวิธีแก้คืนก่อนทำรายการจริง โดยเฉพาะ Web App ที่รับข้อมูลจากฟอร์ม Import และ API หลายระบบ

เริ่มจากนิยามว่า Customer หนึ่งรายคืออะไร

ถ้าระบบใช้กับร้านค้าปลีก Customer อาจหมายถึงบุคคลที่ซื้อสินค้า แต่ถ้าเป็นธุรกิจ B2B ลูกค้าหนึ่งองค์กรอาจมีหลายสาขาและหลายคนที่ประสานงานด้วย การทำ Unique จากชื่อบริษัทอย่างเดียวจึงทำให้ข้อมูลสาขาถูกมองเป็นแถวซ้ำ ทั้งที่ควรเป็นความสัมพันธ์แบบ Company, Branch และ Contact ที่ต่างกัน

ให้ตั้งรหัสภายในที่ไม่เปลี่ยนเมื่อชื่อหรือเบอร์เปลี่ยน เช่น Customer ID หรือ Contact ID แล้วแยกคีย์ภายนอกที่ยืนยันจากระบบต้นทางออกจากสัญญาณช่วยค้นหา ชื่อคนหรืออีเมลเป็นข้อมูลที่เปลี่ยนแปลงได้ และเบอร์สำนักงานหนึ่งเบอร์อาจใช้ร่วมกันหลายคน อย่าตัดสินว่า Record ต้องเป็นบุคคลเดียวจากตัวบ่งชี้ที่มีข้อยกเว้น

เขียน Identity Rule เป็นตารางว่าคีย์ใดห้ามซ้ำแน่นอน คีย์ใดซ้ำได้ และคู่ข้อมูลใดควรถูกส่งให้คนตรวจ เช่น External Record ID จากระบบเดียวกันอาจใช้กันการ Import ซ้ำได้ ส่วนชื่อกับเบอร์ที่ตรงกันอาจเป็นเพียง Candidate ไม่ใช่หลักฐานให้ Merge อัตโนมัติ

แยก Duplicate แน่นอน กับ Duplicate ที่น่าสงสัย

กรณีแรกคือเหตุการณ์เดียวถูกส่งซ้ำ เช่น Webhook จากต้นทางให้ Event ID เดิมสองครั้ง และระบบควรป้องกันการสร้าง Record ใหม่ซ้ำ หากไม่มีข้อมูลเปลี่ยน กรณีที่สองคือคนเดิมอาจเข้ามาจากเว็บไซต์และแชต โดยชื่อสะกดไม่ตรงแต่เบอร์ใกล้เคียง ต้องขอหลักฐานเพิ่ม กรณีที่สามคือสองคนใช้ชื่อหรือช่องทางร่วมกันจริง ซึ่งไม่ควรถูก Merge เลย

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

ถ้ายืนยันไม่ได้ให้ใช้สถานะ Pending Review หรือ Keep Separate และเก็บเหตุผลที่ตัดสิน การปล่อยรายการไว้แยกชั่วคราวอาจถูกต้องกว่า Merge ผิดทันที ธุรกิจควรรับความไม่แน่นอนแบบมีหลักฐาน แทนการบังคับให้ยอดข้อมูลดูสะอาดบนหน้ารายงาน

Unique Constraint ช่วยป้องกันค่าซ้ำ แต่ไม่ใช่ตัวตรวจคนซ้ำทั้งหมด

ในฐานข้อมูลสามารถกำหนด Unique Constraint ให้บางฟิลด์ เช่น External ID ที่มีความหมายว่าไม่ซ้ำตามระบบต้นทาง PostgreSQL อธิบายว่า Unique Constraint ปกติรองรับด้วยดัชนีและมีพฤติกรรมเฉพาะสำหรับ NULL จึงต้องกำหนดให้ชัดว่าข้อมูลว่างหลายรายการหมายถึงอะไร ไม่ใช่ใส่ Unique ในคอลัมน์อีเมลทุกกรณีแล้วถือว่าปิดปัญหาทั้งหมด

การตรวจที่หน้าเว็บด้วย JavaScript เพียงอย่างเดียวไม่พอ เพราะคำขอจากสองหน้าต่างอาจเข้ามาในเวลาใกล้กัน ทั้งคู่ตรวจว่าชื่อยังไม่มี แล้วบันทึกพร้อมกันจนเกิดแถวซ้ำ ต้องกำหนดความถูกต้องฝั่ง Server และ Database รวมถึงกติกาการจัดการเมื่อบันทึกชนกันตามโครงสร้างระบบนั้น ๆ

แนวทาง Input Validation ของ OWASP ให้ตรวจความถูกต้องบน Server และกำหนดกฎข้อมูลอย่างชัด ขณะที่เงื่อนไขทางธุรกิจ เช่น ชื่อลูกค้าสะกดคล้ายกันแต่ไม่ใช่คนเดียวกัน ต้องใช้กฎ Identity ที่เหมาะสมเพิ่ม ไม่ใช่เอา Regex ตรวจเบอร์โทรมาแทนการยืนยันตัวตน

วิเคราะห์ผลกระทบก่อนรวม Record

ก่อน Merge ต้องรู้ว่า Customer ID ทั้งสองผูกกับใบเสนอราคา คำสั่งซื้อ ประวัติชำระเงิน ตั๋วงานบริการ เอกสารแนบ และข้อความแชตอะไรบ้าง ทำ Impact Map แสดงจำนวนรายการแต่ละชนิดและปลายทางที่จะย้ายไปยัง Record หลัก หากคำสั่งซื้อมีเงื่อนไขเป็นขององค์กรคนละแห่ง การรวมอาจขัดกับกระบวนการธุรกิจ แม้ชื่อผู้ติดต่อจะตรงกัน

เพิ่มการตรวจสิทธิ์ตาม Action และ Object ให้ชัด OWASP แนะนำว่าการมีสิทธิ์ดูข้อมูลหนึ่งรายการไม่ได้แปลว่ามีสิทธิ์แก้หรือดูอีกทุกรายการ และควรตรวจสิทธิ์ในทุก Request ดังนั้นการซ่อนปุ่ม Merge ใน UI จึงไม่พอ ต้องตรวจคำขอ API ด้วย และควรแยกสิทธิ์ Merge ออกจาก Edit Contact

ดูวิธีวาง Permission Matrix สำหรับระบบหลังบ้าน เพิ่มเติม โดยกำหนดว่าใครสร้าง Candidate ใครตรวจข้อมูล และใครยืนยันการรวมรายการที่มีผลต่อเอกสารการเงิน อย่าให้คนที่มีหน้าที่พิมพ์เบอร์โทรสามารถรวมข้อมูลข้ามบริษัทโดยไม่มีการทบทวน

ตาราง Merge Decision ที่ทีมธุรกิจใช้คุยกับ Developer ได้

ตารางขั้นต่ำควรมี Candidate A, Candidate B, เหตุผลที่คิดว่าซ้ำ, ข้อมูลที่ใช้ยืนยัน, Record หลักที่จะเก็บ, รายการเกี่ยวข้องที่จะย้าย, ผู้ตรวจ และผู้อนุมัติ เพิ่มสถานะ Keep Separate, Related Accounts, Merge Approved และ Needs Evidence เพื่อให้ทุกคนรู้ว่าแถวไหนอยู่ขั้นตอนไหน

กำหนด Field Merge Rule ไว้ด้วย เช่น หากชื่อจากแถว A ผ่านการยืนยันล่าสุด แต่แถว B มีหมายเลขโทรศัพท์เพิ่มเติม จะเก็บทั้งสองอย่างหรือไม่ และถ้าฟิลด์ในแถว B เป็นค่าว่างจะทับข้อมูลดีจากแถว A หรือเปล่า หาก Consent การติดต่อไม่เหมือนกันห้ามเลือกสถานะที่อนุญาตมากที่สุดเพียงเพราะทีมอยากส่งข้อความต่อ

สำหรับข้อมูลจากระบบเก่า ควรแยกการตรวจความพร้อมก่อน Import ออกจากการรวมหลัง Import คู่มือ การเตรียมย้ายข้อมูลเข้า Web App ช่วยทีมทำ Source Register และ Mapping ก่อนย้าย ส่วนคู่มือนี้ใช้ในขั้นที่ต้องจัดการตัวตนและความสัมพันธ์ของ Record อย่างระมัดระวัง

ตัวอย่างสมมติ: Lead จากเว็บไซต์เจอข้อมูลคล้ายกันใน CRM

สมมติคุณเอกรอกแบบฟอร์มเว็บไซต์เพื่อขอใบเสนอราคา อีกวันทีมฝ่ายขาย Import รายชื่อจากงานอีเวนต์เข้ามา ชื่ออังกฤษสะกดต่างแต่เบอร์โทรตรงกัน ระบบตั้งสถานะ Duplicate Candidate และแสดงสองแหล่งข้อมูลให้เจ้าหน้าที่ตรวจ โดยไม่ผสานรายการทันที

หากตรวจและยืนยันว่าเป็นบุคคลเดียวกัน จึงเลือก Customer ID หลักตามกฎ เก็บ Source IDs ของทั้งสองระบบไว้เพื่ออ้างอิง และตรวจว่าคำขอใบเสนอราคาเดิมไม่หายไปหลัง Merge แต่ถ้าเป็นเบอร์โทรบริษัทที่พนักงานสองคนใช้ร่วมกัน ต้อง Keep Separate พร้อมบันทึกเหตุผล ไม่ให้ระบบเอาเอกสารของสองคนมารวมผิด

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

ต้องมี Undo Plan ไม่ใช่อาศัย Backup ทั้งระบบอย่างเดียว

Merge ที่ผิดอาจต้องแก้เฉพาะประวัติและเอกสารบางรายการ การย้อนฐานข้อมูลทั้งระบบกลับไปเมื่อวานอาจทำให้คำสั่งซื้อที่ถูกต้องของคนอื่นหาย จึงควรออกแบบ Mapping แถวเดิมกับแถวหลัก เก็บผลก่อนและหลัง และมีแผนแยกรายการออกได้หากพบว่าเป็นคนละราย

Audit Entry ควรบอก Merge ID, Source IDs, Target ID, ผู้สั่ง ผู้อนุมัติ เวลา และผลลัพธ์โดยไม่บันทึกข้อมูลลับมากเกินความจำเป็น ต้องรู้ว่าเอกสารใดถูกย้ายไปเพราะเหตุการณ์ใด หากระบบมีหลายทีม ให้กำหนดช่องทางแจ้งเจ้าของงานที่ได้รับผลกระทบด้วย

ทดสอบกรณี Import ซ้ำ, API ส่งซ้ำ, สองคนอนุมัติพร้อมกัน, ผู้ใช้ไม่มีสิทธิ์เรียก API Merge และการย้อนรายการหลังแก้ผิด ผลตรวจที่ดีไม่ใช่แค่ชื่อซ้ำหาย แต่เป็นการรักษาความสัมพันธ์กับเอกสารอย่างถูกต้องและไม่ทำลายประวัติ

แปลงเรื่อง Duplicate ให้เป็น Requirement ที่ทดสอบได้

หากทีมกำลังจ้างพัฒนาระบบ อย่าส่งโจทย์เพียงว่า “ช่วยลบรายชื่อลูกค้าซ้ำ” ให้ระบุ Data Objects, Identity Rule, Source IDs, Unique Keys, Candidate Queue, Approval Rule และวิธี Restore ให้ครบ กำหนดว่าข้อมูลจากเว็บไซต์ CRM หรือ Excel แต่ละช่องทางจะส่งคีย์ใดมา และระบบต้องตอบเมื่อคีย์ชนกันอย่างไร

เขียน Acceptance Test แบบเห็นผล เช่น เมื่อ Event ID เดิมเข้าซ้ำต้องไม่มี Record ใหม่ เมื่อผู้ไม่มีสิทธิ์พยายาม Merge ต้องถูกปฏิเสธ เมื่อเลือก Keep Separate ระบบต้องไม่รวมในรอบ Import ถัดไปโดยอัตโนมัติ และเมื่อมีการ Merge ต้องย้อนตรวจต้นทางได้โดยไม่เปิดเผยข้อมูลของคนอื่น

หากยังไม่ได้วาดงานจริง ให้เริ่มจาก Requirement Discovery ก่อนพัฒนา Web App เพื่อเห็นว่าข้อมูลมาจากใครและต้องผ่านจุดตรวจอะไร จากนั้นจึงเลือกเทคโนโลยีฐานข้อมูลหรือหน้าจอที่เหมาะ ไม่ควรเลือกเครื่องมือเพียงเพราะมีปุ่ม Merge สำเร็จรูป

สรุป: พบว่าคล้ายกันก่อน ยังไม่ใช่ได้รับอนุญาตให้ลบ

ระบบหลังบ้านที่ไว้ใจได้ต้องรู้ว่า Customer หนึ่งรายหมายถึงอะไร ใช้ ID ที่ไม่เปลี่ยนตามชื่อหรือเบอร์ และแยก Duplicate Detection ออกจากการยืนยันกับการ Merge เอกสารที่เกี่ยวข้องต้องไม่สูญหาย ผู้มีสิทธิ์ต้องชัด และทุกเหตุการณ์ควรมีทางตรวจย้อนกลับ

สำหรับธุรกิจที่ต้องทำ CRM ระบบสมาชิกหรือการรวมข้อมูลจากหลายช่องทาง สามารถพิจารณา บริการพัฒนา Web App สำหรับธุรกิจ โดยใช้ Identity Rule, Impact Map และ Acceptance Cases เป็นโจทย์เริ่มต้น ไม่ใช่ใช้การลบชื่อซ้ำเพื่อให้ตัวเลขบน Dashboard สวยอย่างเดียว

คำถามที่พบบ่อย

เบอร์โทรซ้ำแปลว่าเป็นลูกค้าคนเดียวกันหรือไม่?

ไม่เสมอไป เบอร์อาจใช้ร่วมกันหรือเปลี่ยนเจ้าของ ต้องตรวจตาม Identity Rule และหลักฐานอื่นก่อน Merge

ควรลบ Record ที่ดูซ้ำทันทีไหม?

ไม่ควร ตรวจเอกสารและสิทธิ์ของแต่ละ Record ก่อน และเลือก Keep Separate หรือ Pending Review เมื่อข้อมูลไม่เพียงพอ

Unique Constraint ป้องกันคนซ้ำได้ทั้งหมดไหม?

ไม่ได้ มันป้องกันค่าตามคีย์ที่กำหนด แต่ไม่เข้าใจความหมายของบุคคล ชื่อเปลี่ยนหรือเบอร์ร่วมกันยังต้องใช้ Business Rule

Merge ผิดแล้วสามารถย้อนกลับได้ไหม?

ต้องวางแผนล่วงหน้า เก็บ Mapping ID ประวัติการเปลี่ยนและแผนแก้เฉพาะรายการ โดยไม่อาศัย Restore ทั้งฐานเพียงอย่างเดียว

แหล่งอ้างอิง

• OWASP Cheat Sheet Series. Input Validation Cheat Sheet — มาตรฐานเทคนิคประกอบการออกแบบและตรวจข้อมูล (ตรวจ 4 พฤศจิกายน 2026)
• OWASP Cheat Sheet Series. Authorization Cheat Sheet — มาตรฐานเทคนิคประกอบการออกแบบและตรวจข้อมูล (ตรวจ 4 พฤศจิกายน 2026)
• PostgreSQL Documentation. Constraints — Unique constraints — มาตรฐานเทคนิคประกอบการออกแบบและตรวจข้อมูล (ตรวจ 4 พฤศจิกายน 2026)