ทริกเกอร์ของ SQL และเมื่อใดหรือเมื่อใดที่จะไม่ใช้

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

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

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

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

การสนทนาต่อไปนี้ใช้ SQL Server เท่านั้น

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

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

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

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

อาจเป็นสาเหตุของเรื่องนี้คือ:

1. บางฟังก์ชั่นที่ใช้เรียกใช้ในวันเก่าสามารถทำได้ในรูปแบบอื่นเช่นการปรับปรุงยอดรวมและการคำนวณอัตโนมัติในคอลัมน์
2. คุณไม่เห็นว่ามีการเรียกใช้ทริกเกอร์อย่างไรโดยตรวจสอบรหัสเพียงอย่างเดียวโดยที่ไม่รู้ว่ามีอยู่หรือไม่ คุณเห็นผลกระทบของมันเมื่อคุณเห็นการเปลี่ยนแปลงของข้อมูลและบางครั้งก็ทำให้งงงวยที่จะคิดว่าทำไมการเปลี่ยนแปลงที่เกิดขึ้นนอกเสียจากว่าคุณรู้ว่ามีทริกเกอร์หรือทำหน้าที่มากกว่าบนโต๊ะ
3. หากคุณใช้การควบคุมฐานข้อมูลหลายอย่างเช่น CHECK, RI, ทริกเกอร์ในหลาย ๆ ตารางการทำธุรกรรมของคุณจะมีความซับซ้อนเพื่อทำความเข้าใจและบำรุงรักษา คุณจะต้องรู้ว่าเกิดอะไรขึ้นเมื่อ อีกครั้งคุณจะต้องมีเอกสารที่ดีสำหรับเรื่องนี้

ความแตกต่างบางอย่างระหว่างทริกเกอร์และโพรซีเดอร์ที่จัดเก็บแบบไม่ทริกเกอร์คือ (ในจำนวนอื่น ๆ ):

• โพรซีเดอร์ที่เก็บแบบไม่ทริกเกอร์เป็นเหมือนโปรแกรมที่ต้องถูกเรียกใช้อย่างชัดเจนไม่ว่าจะเป็นจากรหัสหรือจากตัวจัดตารางเวลาหรือจากงานแบ็ตช์ ฯลฯ เพื่อทำงานในขณะที่ทริกเกอร์ aa เป็นโพรซีเดอร์ที่จัดเก็บชนิดพิเศษ การตอบสนองของเหตุการณ์แทนที่จะดำเนินการโดยตรงโดยผู้ใช้ เหตุการณ์อาจเป็นการเปลี่ยนแปลงข้อมูลในคอลัมน์ข้อมูลตัวอย่างเช่น
• ทริกเกอร์มีประเภท ทริกเกอร์ DDL และทริกเกอร์ DML (จากประเภท: INSTEAD OF, For และ AFTER)
• กระบวนงานที่เก็บไม่ทริกเกอร์สามารถอ้างอิงวัตถุชนิดใดก็ได้อย่างไรก็ตามในการอ้างอิงมุมมองคุณต้องใช้ทริกเกอร์ INSTEAD OF
• ใน SQLServer คุณสามารถมีหมายเลขใด ๆ บนโพรซีเดอร์ที่เก็บทริกเกอร์ไม่ได้ แต่ทริกเกอร์ INSTEAD OF 1 ต่อตารางเท่านั้น

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

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

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

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

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

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

การใช้ทริกเกอร์ฐานข้อมูล

1. เพื่อผลักดันค่าคอลัมน์โดยอัตโนมัติ
2. เพื่อบังคับใช้ข้อ จำกัด ด้านความสมบูรณ์ที่ซับซ้อน
3. เพื่อบังคับใช้กฎเกณฑ์ทางธุรกิจที่ซับซ้อน
4. ในการปรับแต่งการอนุญาตด้านความปลอดภัยที่ซับซ้อน
5. เพื่อรักษาตารางทำซ้ำ
6. เพื่อตรวจสอบการดัดแปลงข้อมูล

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

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

ทริกเกอร์สามารถใช้เพื่อบังคับใช้ข้อ จำกัด ในฐานข้อมูลซึ่งไม่สามารถบังคับใช้ในระหว่างการสร้างสกีมาฐานข้อมูลและคำสั่ง DML ใด ๆ

ให้บอกว่าคุณต้องส่งข้อมูลไปยังระบบของบุคคลที่สามในเวลาจริง ตารางของคุณมีข้อมูล 950 กิกะไบต์ดังนั้นมันใหญ่เกินไปที่จะเพียงแค่ดันทั้งตารางไปยังแอปของบุคคลที่สาม

คุณสะสมการเปลี่ยนแปลงในคิวแทน จากนั้นโปรแกรมภายนอกบางโปรแกรมจะส่งข้อมูลที่อยู่ในคิวเป็นระยะ ๆ

ระบบมีขั้นตอนการจัดเก็บมากกว่า 2,000 รายการ คุณยังรู้ว่ามี sql จำนวนมากในซอร์สโค้ด ในการรับประกันว่าคิวจะได้รับการบรรจุอย่างถูกต้องคุณจะต้องค้นหาโปรแกรมและโค้ดที่เก็บไว้ทั้งหมดและหวังว่าคุณจะไม่พลาดอะไร

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

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

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

ฉันยังเสนอการสังเกตว่าทริกเกอร์สามารถรักษาได้ง่ายโดยเรียกใช้ขั้นตอนการจัดเก็บ / ฟังก์ชั่นที่อาจซับซ้อนโดยพลการและอาจนำมาใช้ซ้ำได้โดยทริกเกอร์หลายตัวหรือขั้นตอนการจัดเก็บอื่น ๆ นั่นคือเหตุผลที่มีแพ็คเกจและไลบรารี

ความดื้อรั้นเป็นสิ่งที่ทำให้ทรุดโทรมจริงๆ