ฉันต้องการทริกเกอร์สำหรับฐานข้อมูลเชิงสัมพันธ์เช่น PostgreSQL หรือไม่

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

ตัวอย่างเช่นเราเก็บลูกค้าและเราต้องการทำการตรวจสอบบางอย่างที่ไม่สามารถทำได้ในระดับ DDL https://severalnines.com/blog/postgresql-triggers-and-stored-function-basics

อีกตัวอย่างหนึ่งคือการตรวจสอบ

ปรับปรุง

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

ขึ้นอยู่กับประเภทของระบบแอปพลิเคชันที่คุณกำลังสร้าง:

• หากคุณกำลังสร้างระบบแอปพลิเคชั่นเป็นศูนย์กลางซึ่งมีเพียงหนึ่งแอปพลิเคชันหลักโดยมีฐานข้อมูลเฉพาะสำหรับแอปพลิเคชันนี้โดยเฉพาะและทีมหนึ่งที่มีหน้าที่รับผิดชอบในการพัฒนาแอปพลิเคชันและฐานข้อมูลแบบเคียงข้างกัน ตรรกะภายในแอปพลิเคชัน

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

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

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

ดูเพิ่มเติมที่โพสต์เก่า SE: Application Logic Vs DB Triggers สำหรับการทำความสะอาดฐานข้อมูล

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

ฉันคิดว่าคำถามเกี่ยวกับความรับผิดชอบต่อคุณภาพของข้อมูล

คำตอบขึ้นอยู่กับว่าคุณเห็นระบบอย่างไร

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

ในทางกลับกันฐานข้อมูลอาจถูกพิจารณาว่าเป็นรูปแบบของไฟล์ที่ซับซ้อนซึ่งอยู่ภายใต้การควบคุมโดยตรงและทั้งหมดของแอปพลิเคชัน ในแง่นี้ฐานข้อมูลจะกลายเป็นเครื่องมือการทำให้เป็นอนุกรมและเครื่องมือนำทางเอกสารอย่างแท้จริง มันอาจมีพฤติกรรมขั้นสูงบางอย่างเพื่อสนับสนุนการสืบค้นและการบำรุงรักษาเอกสาร (เช่นเครื่องมือ JSON หรือเครื่องมือ XML) แต่จากนั้นก็ไม่จำเป็นต้องทำเช่นนั้น (เช่นสตรีมไฟล์ส่วนใหญ่จะทำ) ในกรณีนี้มันเป็นความรับผิดชอบของโปรแกรมอย่างแท้จริงในการรักษารูปแบบและเนื้อหาที่ถูกต้องภายในไฟล์ ในมุมมองนี้มีแอปพลิเคชั่นเดียวอยู่

ในทั้งสองมุมมองคำถามต่อไปคือวิธีการสนับสนุนการใช้ฐานข้อมูลเป็นไฟล์แฟนซีหรือบริการแยกต่างหาก คุณสามารถทำได้โดย:

• ใช้เครื่องมือที่แพลตฟอร์มฐานข้อมูลจัดทำในรูปแบบของตาราง / มุมมอง / ขั้นตอนการจัดเก็บ / ทริกเกอร์ / ฯลฯ ...
• การรวมฐานข้อมูลไว้ภายในเซอร์วิสที่ไคลเอ็นต์ทั้งหมดต้องใช้เพื่อเข้าถึงฐานข้อมูล
• การห่อฐานข้อมูลในไลบรารีที่ไคลเอ็นต์ทั้งหมดต้องใช้เพื่อเข้าถึงข้อมูล

แต่ละคนมาพร้อมกับข้อดี / ข้อเสียของตัวเองและจะขึ้นอยู่กับข้อ จำกัด ทางสถาปัตยกรรมของสภาพแวดล้อมที่ระบบทำงานภายใน

ไม่ว่าคุณจะใช้มุมมองแบบใดจะจ่ายเพื่อตรวจสอบข้อมูลตามขอบเขตเสมอ

• ตรวจสอบความถูกต้องของฟิลด์บน UI ที่ผู้ใช้ป้อน
• ตรวจสอบคำขอเครือข่าย / API ก่อนที่จะออกจากไคลเอนต์
• ตรวจสอบคำขอเครือข่าย / API ในเซิร์ฟเวอร์ก่อนทำอะไร
• ตรวจสอบข้อมูลที่ส่งผ่านไปยังกฎเกณฑ์ทางธุรกิจ
• ตรวจสอบข้อมูลก่อนที่จะยืนยัน
• ตรวจสอบความถูกต้องของข้อมูลหลังจากได้รับข้อมูลจากการคงอยู่
• เป็นต้น

การตรวจสอบความถูกต้องแต่ละขอบเขตนั้นขึ้นอยู่กับความเสี่ยงที่จะไม่ตรวจสอบความถูกต้อง

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

ไม่คุณไม่ควรใช้ทริกเกอร์เพื่อตรวจสอบความถูกต้อง

ฐานข้อมูลรับผิดชอบต่อความถูกต้องสมบูรณ์ของตัวเองเท่านั้น แอปพลิเคชันของคุณต้องมีการตรวจสอบความถูกต้อง

ฐานข้อมูลดำเนินการตรวจสอบสามระดับเพื่อความสมบูรณ์ คนแรกคือการตรวจสอบระดับสนาม จำเป็นต้องกรอกข้อมูลในฟิลด์หากไม่มีค่า (null) เป็นข้อผิดพลาด นอกจากนี้ยังสามารถตรวจสอบข้อ จำกัด ; โดเมนมีจำนวนค่าที่แจกแจง

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

ประการที่สามและซับซ้อนที่สุดเป็นตัวกระตุ้น ตามกฎทั่วไปสิ่งเหล่านี้ควรจะอยู่ (ไม่ตั้งใจ) ไม่เกี่ยวข้องกับกฎความสมบูรณ์ที่มีเงื่อนไข หากต้องการกลับมาที่ตัวอย่างที่อยู่: หากประเทศไม่มีรหัสไปรษณีย์อาจเป็นปัญหาหากประเทศในรายการนี้มีรหัสไปรษณีย์ ดังนั้นการตรวจสอบจะเป็น: หากประเทศนี้ไม่มีรหัสไปรษณีย์เขตข้อมูลรหัสไปรษณีย์ควรเป็นค่าว่าง

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

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

การตรวจสอบสามารถทำได้ในระดับ front end แต่ฉันเห็นข้อผิดพลาดแปลก ๆ ในฐานข้อมูลที่ฉันจัดการ (ผู้ที่เกิดใน 3000 ฯลฯ ) และเนื่องจากบางส่วนของพวกเขาฉันทำเองฉันขอแนะนำให้มีเลเยอร์เพิ่มเติม ของการตรวจสอบในฐานข้อมูลในกรณี แน่นอนข้อผิดพลาดประเภทนั้นสามารถหลีกเลี่ยงได้ด้วยข้อ จำกัด การตรวจสอบและหลายครั้งพวกเขามีประสิทธิภาพมากขึ้น (ใน MS SQL พวกเขาเป็นวิธีที่ต้องการ; ตรวจสอบเอกสารประกอบเสมอ)

เนื่องจากคำถามนั้นเกี่ยวกับถ้าเราต้องการทริกเกอร์สำหรับฐานข้อมูลเชิงสัมพันธ์ที่นี่เป็นกรณีการใช้งานอื่นที่จะใช้ทริกเกอร์:

1. สำหรับการตรวจสอบตามที่อธิบายไว้ในคำตอบอื่น ๆ
2. การตรวจสอบในแง่ที่กว้างขึ้น: หากมีการเปลี่ยนแปลงรายการฐานข้อมูลทริกเกอร์สามารถบันทึกเหตุการณ์สำหรับการโพสต์แบบ asychroneous เช่นการส่งออกทุกคืนไปยังแอปพลิเคชันอื่น
3. ทริกเกอร์สำหรับมุมมอง: instead ofทริกเกอร์สามารถกำหนด ด้วยค่าเฉลี่ยนี้สามารถแทรกอัปเดตและลบรายการจากมุมมองได้ ทริกเกอร์สามารถกระจายการกระทำเหล่านี้ไปยังหลาย ๆ ตาราง นี่เป็นวิธีที่จะทำให้มุมมองแบบ จำกัด ใช้ได้โดยไม่ต้องเปิดเผยรายละเอียดของตารางต้นแบบ
4. ในการบันทึกฐานข้อมูลอย่างชัดเจน: สมมติว่าความสัมพันธ์ N: M ระหว่างตาราง A และ B และตารางกลาง R คุณสามารถกำหนดข้อ จำกัด คีย์ต่างประเทศจาก R เป็น A และ B ระบุว่ารายการใน R จะถูกลบหาก รายการที่เกี่ยวข้องใน B ถูกลบ อย่างไรก็ตามตรรกะทางธุรกิจต้องการบางครั้งว่ารายการใน A ต้องมีความสัมพันธ์กับรายการใน B อย่างน้อยหนึ่งรายการในกรณีนี้ทริกเกอร์การลบ R สามารถช่วยบังคับใช้ตรรกะนี้ได้: สำหรับรายการใน A รายการสุดท้ายใน R จะถูกลบจากนั้นทริกเกอร์สามารถลบ A. ในมุมมองศูนย์กลางการสมัครอย่างน้อยสองรอบมีความจำเป็น นี่คือตัวอย่างสำหรับการตรวจสอบ ตัวอย่างอื่น ๆ ที่นึกออก: ข้างๆกรณีการใช้งาน (1), (2),
5. ความน่าเชื่อถือ: บางครั้งผู้ดูแลฐานข้อมูลเปลี่ยนรายการในบรรทัดคำสั่งที่ไม่ได้ใช้แอปพลิเคชันของคุณ ผู้ดูแลระบบทำงานอย่างระมัดระวังและรู้ว่าพวกเขาทำอะไร อย่างไรก็ตามบางครั้งพวกเขาอาจผิด หากความมั่นคงมีความสำคัญสิ่งกระตุ้นคือเข็มขัดนิรภัย

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