มีกระบวนการทางธุรกิจอย่างน้อย 2 กระบวนการที่เกี่ยวข้องที่นี่
แสดงที่นั่งว่าง
จองที่นั่งที่เลือก
เนื่องจากกระบวนการเหล่านี้ไม่ได้ติดตามกันอย่างไม่สุภาพและเนื่องจาก 2 คนอาจเลือกที่นั่งเดียวกันที่มีปัญหาเกิดขึ้นพร้อมกัน
หากการออกแบบฐานข้อมูลของคุณกำหนดข้อ จำกัด ที่ไม่ซ้ำกันที่ถูกต้องเพื่อให้การรวมกันของ:
-TheaterID
-SeatID
-EventID
ไม่ซ้ำกันจากนั้นฐานข้อมูลจะป้องกันการซ้ำซ้อน
สถานการณ์ต่อไปนี้เป็นไปได้เช่นกัน แต่จะได้รับการดูแลโดยการนำไปปฏิบัติที่แนะนำข้างต้น:
สมมติว่ามุมมองกริดที่มีให้สำหรับโรงละครที่กำหนดและเหตุการณ์ที่กำหนดสามารถแสดงได้:
- User1 แสดงที่นั่งว่าง (และรับที่นั่ง 1 และ 2)
- User2 แสดงที่นั่งว่าง (และรับที่นั่ง 1 และ 2)
- User1 พูดกับลูกค้าทางโทรศัพท์เล็กน้อย
- ผู้ใช้ไปที่ 2 และจองที่นั่ง 2 สำหรับลูกค้าของเขา
- ผู้ใช้ 1 พยายามจองที่นั่ง 2 สำหรับลูกค้าของเขา (เพราะมันแสดงให้เห็นว่ามีอยู่บนหน้าจอของเขา)
- ดัชนีที่ไม่ซ้ำกันป้องกันขั้นตอนที่ 5 จากการเดินทางข้อมูล
ดังนั้นสิ่งที่คุณต้องทำอาจจะไม่มีอะไรที่ถูกต้องในการออกแบบฐานข้อมูลและทางเลือกที่เหมาะสมกับข้อ จำกัด
วิธีการที่ซับซ้อนกว่านี้เป็นไปได้หากคุณต้องการโดยใช้คิวธุรกรรม ในกรณีนี้คำขอถูกเขียนลงในคิวก่อนแล้วจึงทำการประมวลผลทุก ๆ n วินาที แต่แทบจะไม่จำเป็นหรือใช้งานได้จริงในกรณีของคุณ
ส่วนที่น่าสนใจคือตารางรายการสำหรับผู้ใช้ 1 ควรแสดงอย่างไร