यह विशेष पैटर्न वास्तव में काफी खतरनाक है क्योंकि यह किसी को मैन्युअल रूप से एक नई आईडी इनपुट करने की अनुमति देता है जो पहले से मौजूद सरोगेट कुंजी के साथ संघर्ष कर सकता है या भविष्य में आपका अनुक्रम उत्पन्न हो सकता है।
आपका ट्रिगर वास्तव में इस तरह दिखना चाहिए ताकि यह सुनिश्चित हो सके कि प्रत्येक नए रिकॉर्ड के लिए एक अद्वितीय कुंजी प्राप्त हो। यदि आप 11.2 या उच्चतर का उपयोग कर रहे हैं तो select ... into ... . की कोई आवश्यकता नहीं है
CREATE OR REPLACE TRIGGER TEST_TRIG
BEFORE INSERT ON my_table
FOR EACH ROW
BEGIN
:new.column1 := my_table_seq.NEXTVAL;
END;
इस दृष्टिकोण का लाभ यह है कि यह हमेशा है किया हुआ। इस कॉलम के लिए कोई भी मूल्य जो भी डालता है वह उस चीज़ पर अधिलेखित हो जाता है जो काम करेगी और जो सही अनुक्रम का उपयोग करती है; अगर कोई इसे स्टेटमेंट में जोड़ना भूल जाता है तब भी काम करेगा।
यह आपकी सरोगेट कुंजी को तोड़ना असंभव बना देता है।
आप जो सुझाव देते हैं, उसके साथ कल्पना करें कि कोई व्यक्ति इसके बजाय 1 रखता है; आपको प्राथमिक कुंजी उल्लंघन मिलता है। अगर कोई भूल जाता है तो और भी गलतियाँ हैं। आप इस बात की कभी गारंटी नहीं देंगे कि आपकी तालिका का प्रत्येक अपडेट एक प्रविष्टि के माध्यम से होगा, इसलिए ट्रिगर गारंटी देता है कि पीके सही ढंग से भरा हुआ है।
यह ध्यान देने योग्य है कि 12c से आप पहचान का उपयोग कर सकते हैं। स्तंभ , जो टेबल और ऑटो-इन्क्रीमेंट के बीच की कड़ी को स्पष्ट करता है; ट्रिगर या अनुक्रम की कोई आवश्यकता नहीं है। टेबल निर्माण डीडीएल के लिए सिंटैक्स होगा:
create table <table_name> ( <column_name> generated as identity );
