ฐานข้อมูลก่อให้เกิดความชั่วร้ายหรือไม่? [ปิด]

ฐานข้อมูลก่อให้เกิดความคิดที่ไม่ดีหรือไม่?

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

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

ModifiedDateโดยเฉพาะเวลาที่เรากำลังใช้ทริกเกอร์สำหรับสิ่งที่ง่ายจริงๆเช่นการตั้งค่า

ปัญหาหลักของทริกเกอร์คือ

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

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

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

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

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

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

เครื่องมือไม่เคยชั่วร้าย การใช้เครื่องมือเหล่านั้นอาจเป็นสิ่งที่ชั่วร้าย

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

ความสำคัญของทริกเกอร์ (ในใจของฉัน) ก็คือ ...
- ระบบใด ๆ ควรอยู่ในสถานะที่ถูกต้องเสมอ
- รหัสเพื่อบังคับใช้สถานะที่ถูกต้องนี้ควรรวมศูนย์ (ไม่เขียนใน SP ทุกตัว)

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

ฉันเดาว่ามันจะขึ้นกับสภาพแวดล้อมการทำงานของคุณ คุณมีคนที่เชื่อถือได้ที่เรียนรู้ได้ดีและสามารถเชื่อถือได้ว่ามีระเบียบหรือไม่? หากไม่ใช่คุณมีสองทางเลือก:
- ยอมรับว่าคุณจะต้องสูญเสียฟังก์ชันการทำงานเพื่อชดเชย
- ยอมรับว่าคุณต้องการคนที่แตกต่างหรือต้องการการฝึกอบรมและการจัดการที่ดีกว่า

พวกเขาฟังดูรุนแรงและฉันคิดว่าพวกเขาเป็น แต่มันเป็นความจริงพื้นฐานในใจของฉัน ...

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

ส่วนใหญ่ใช่

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

มันสร้างเลเยอร์ของความซับซ้อนซึ่งเพิ่งเพิ่มงานบำรุงรักษา

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

ทริกเกอร์มีประสิทธิภาพและมีประโยชน์อย่างมากมีจำนวนสถานการณ์ที่ทริกเกอร์เป็นทางออกที่ดีที่สุดสำหรับปัญหา

พวกเขายังเป็นเครื่องมือ "แฮ็ค" ที่ดีมาก มักจะมีสถานการณ์ที่คุณไม่ได้ควบคุมทั้งรหัสและฐานข้อมูลทันที หากคุณต้องรอ 2 เดือนสำหรับการออกรุ่นใหญ่ครั้งต่อไปของคุณ แต่คุณสามารถนำ patch ไปใช้กับฐานข้อมูลของคุณได้ทันทีจากนั้นคุณสามารถวางทริกเกอร์บนโต๊ะเพื่อทำหน้าที่เพิ่มเติม จากนั้นเมื่อการปล่อยรหัสเป็นไปได้คุณสามารถแทนที่ทริกเกอร์นี้ด้วยฟังก์ชั่นการใช้รหัสเดียวกันหากต้องการ

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

ทริกเกอร์มีการใช้งานของพวกเขา - การบันทึก / ตรวจสอบและการบำรุงรักษาวันที่ "แก้ไขล่าสุด" เป็นสองการใช้งานที่ดีมากซึ่งได้รับการกล่าวถึงในการตอบกลับก่อนหน้านี้

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

นอกจากนี้ยังมีปัญหา "หลักการของความประหลาดใจน้อยที่สุด" ที่ได้รับการกล่าวถึงแล้ว

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

ตอนนี้พวกเขาสามารถเป็น "ความชั่วร้าย" ได้ถ้าคุณจบลงที่ "ทริกเกอร์นรก" ด้วยทริกเกอร์ตัวเดียวที่เริ่มต้นทริกเกอร์อื่น ฉันเคยทำงานกับผลิตภัณฑ์ COTS ซึ่งพวกเขามีสิ่งที่เรียกว่า "ตัวกระตุ้นยืดหยุ่น" ทริกเกอร์เหล่านี้ถูกเก็บไว้ในตารางเนื่องจาก stings sql แบบไดนามิกถูกรวบรวมทุกครั้งครั้งที่ถูกประมวลผล ทริกเกอร์ที่คอมไพล์จะทำการค้นหาและดูว่าตารางนั้นมีทริกเกอร์เฟล็กใด ๆ ให้เรียกใช้จากนั้นรวบรวมและเรียกใช้ทริกเกอร์ "flex" ในทางทฤษฎีสิ่งนี้ฟังดูเป็นไอเดียที่เจ๋งจริงๆเพราะผลิตภัณฑ์นั้นถูกปรับแต่งได้ง่าย แต่ความจริงก็คือฐานข้อมูลนั้นค่อนข้างจะระเบิดเพราะคอมไพล์ทั้งหมดที่มันต้องทำ ...

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

ในระดับสูงมีสองกรณีใช้งานสำหรับทริกเกอร์ 1

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

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

2) เพื่อบังคับใช้กฎความสมบูรณ์ของข้อมูลนอกเหนือจากกฎที่เราสามารถจัดการได้อย่างชัดเจน (โดยใช้ CHECK, คีย์หลัก, UNIQUE KEY และ FOREIGN KEY) ในกรณีใช้งานทริกเกอร์ทั้งหมดจะเป็นข้อมูล QUERY (SELECT) เพื่อตรวจสอบว่าอนุญาตให้ทำการเปลี่ยนแปลง INSERT / UPDATE / DELETE หรือไม่ เช่นเดียวกับข้อ จำกัด ที่เปิดเผยทำให้เรา เฉพาะในกรณีนี้เรา (ผู้พัฒนา) ได้ตั้งโปรแกรมการบังคับใช้

การใช้ทริกเกอร์สำหรับกรณีใช้หลังไม่เป็นอันตราย

ฉันบล็อกที่: http://harmfultriggers.blogspot.com

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

อย่างไรก็ตามฉันเห็นด้วยกับ MarkR อย่างสมบูรณ์ - คุณสามารถ (เกือบ) เขียนโค้ดที่มีฟังก์ชันเทียบเท่ากับทริกเกอร์ที่จะฉลาดกว่าและง่ายต่อการบำรุงรักษา

ไม่ใช่ความชั่วร้าย พวกเขาทำให้สิ่งต่าง ๆ ง่ายขึ้นเช่น

1.Logging / ตรวจสอบการเปลี่ยนแปลงเรคคอร์ดหรือแม้แต่สคีมาฐานข้อมูล

คุณอาจมีทริกเกอร์ใน ALTER TABLE ที่ย้อนกลับการเปลี่ยนแปลงในสภาพแวดล้อมการผลิตของคุณ สิ่งนี้ควรป้องกันการดัดแปลงตารางโดยไม่ตั้งใจ

2. บังคับ intrgrity อ้างอิง (ความสัมพันธ์หลัก / ต่างประเทศคีย์ ฯลฯ ) ในฐานข้อมูลหลาย ๆ

ไม่พวกเขาไม่ใช่คนชั่ว - พวกเขาแค่เข้าใจผิด :-D

ทริกเกอร์มีการใช้งานที่ถูกต้อง แต่บ่อยครั้งที่การแฮ็กย้อนยุคทำให้สิ่งเลวร้ายลงในที่สุด

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

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

การพูดว่าพวกเขาชั่วร้ายนั้นเป็นสิ่งที่น่าตื่นเต้น แต่พวกเขาสามารถทำให้เกิดตาข่ายได้ เมื่อการยิงทริกเกอร์หนึ่งทำให้ทริกเกอร์อื่น ๆ ยิงมันซับซ้อนมาก สมมติว่าพวกเขาลำบาก: http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html

การทำตรรกะทางธุรกิจใน Oracle ด้วยทริกเกอร์นั้นยากกว่าที่คิดเพราะมีปัญหาหลายอย่างพร้อมกัน คุณไม่เห็นการเปลี่ยนแปลงในเซสชั่นอื่นจนกว่าเซสชันอื่นจะทำ

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

พวกเขายังมีประโยชน์มากสำหรับการตรวจสอบ

คำตอบนี้ใช้เฉพาะกับ SQL Server (แม้ว่ามันอาจใช้กับ RDBMS อื่น ๆ ที่ฉันไม่มีความคิดฉันอยากจะให้มันเป็นคำตอบที่นี่แต่มันถูกปิดเหมือนดักฟังของสิ่งนี้)

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

ตัวอย่างที่ให้ไว้ใน BOL ภายใต้หัวข้อ "การจัดการความปลอดภัย Trigger " เป็นของผู้ใช้ที่สร้างทริกเกอร์ที่มีรหัสGRANT CONTROL SERVER TO JohnDoe ;เพื่อเพิ่มสิทธิ์ของตัวเอง

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

ฉันคิดว่าพวกเขาสามารถเป็นคนชั่วร้าย แต่เป็นเพียงสิ่งชั่วร้ายที่จะพัฒนา

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

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

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

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

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

ความคิดของทริกเกอร์ไม่ใช่สิ่งชั่วร้าย