2013-02-05 20 views
6

मेरे पास 120 कॉलम वाली एक टेबल है। मुझे ऑडिट ट्रेल सेट अप करने की आवश्यकता है जो इसे बदलने पर किसी कॉलम को लॉग करेगा। यह अब के रूप में, मुझे लगता है मैं प्रत्येक कॉलम में इस तरह की हालत कुछ के साथ ट्रिगर सेट करने के लिए है लगता है:MySQL अद्यतन ट्रिगर - बदले गए कॉलम ढूंढें?

IF(NEW.columnName != OLD.columnName) 
THEN //log the old value 

यह 120 बार किया जा करने की आवश्यकता होगी ... मैं इस दृष्टिकोण स्वीकार कर लिया है जबकि 20 साल पहले, आज मैं यह मानने से इनकार करता हूं कि इस तरह की एक सरल प्रक्रिया को स्वचालित रूप से परिवर्तित कॉलम ढूंढना असंभव है। या कुछ इसी तरह

  • न तो नई है और न ही पुराने एक टेबल है, यह एक भाषा निर्माण का एक प्रकार है की वजह आप ऐसा नहीं कर सकते:

    यह वही है मैं अब तक की खोज की है "अभी चुनें *।"।

  • ट्रिगर्स में डायनामिक एसक्यूएल की अनुमति नहीं है (इससे समस्या हल हो सकती है)।
  • गतिशील एसक्यूएल का उपयोग करने वाली प्रक्रियाओं को ट्रिगर्स में अनुमति नहीं है (गंभीरता से, ओरेकल, ऐसा लगता है कि आपने इस सुविधा को अक्षम करने के लिए वास्तव में कड़ी मेहनत की है, इससे कोई फर्क नहीं पड़ता)।

मैं पहले से उपयोग करने के लिए सोच रहा था और अस्थायी तालिकाओं और चर के साथ ट्रिगर्स के बाद जो समस्या को हल कर सकता था, फिर भी गतिशील एसक्यूएल की आवश्यकता होगी। मुझे लगता है कि मैंने एक मृत अंत मारा।

क्या इसका कोई समाधान है?

एक पक्ष प्रश्न: क्या यह PostgreSQL में संभव होगा?

अद्यतन:

  • एक समाधान के गतिशील एसक्यूएल workaround साथ संयोजन के रूप में उपयोग करने के लिए चलाता के रूप में कार्यक्रम का उपयोग कर: मैं 2 संभावित समाधानों लेकिन उनमें से कोई भी मेरे लिए काफी स्पष्ट लग पाया। मुझे स्वीकार करना है, मुझे यह बिल्कुल नहीं मिला है, क्या इसका मतलब यह है कि घटना हर सेकेंड में आग लगती है चाहे कोई फर्क नहीं पड़ता?
  • This article कहता है कि जब तक अस्थायी तालिका का उपयोग नहीं किया जाता है तब तक गतिशील एसक्यूएल का उपयोग ट्रिगर के अंदर करना संभव है। वह अभी भी गतिशील एसक्यूएल का उपयोग कर रहा है, इसलिए मुझे काफी समझ में नहीं आता है।
+0

आप की जाँच की है करने के लिए लिखा जा सकता है यह आपके पिछले प्रश्न के लिए पोस्टग्रेज़ में सत्र सूचना कार्यों के साथ] (http://stackoverflow.com/questions/8759595/within-a-trigger-function-how-to-get-which-fields-are-being-updated) – bonCodigo

+0

@bonCodigo धन्यवाद, स्पष्ट रूप से PostgreSQL इस मामले में अधिक लचीला है। – Caballero

उत्तर

1

दिलचस्प, मुझे गतिशील ट्रिगर-आधारित ऑडिट लॉग को कार्यान्वित करने के साथ कुछ साल पहले एक ही समस्या का सामना करना पड़ रहा था। जिस समाधान के साथ मैं आया था वह केवल एसक्यूएल ट्रिगर कोड उत्पन्न करना था जो तब पुरानी ट्रिगर परिभाषाओं को बदलने के लिए लागू हो सकता है (स्वचालित रूप से)। अगर मेमोरी परोसा जाता है, तो मैंने कुछ एसक्यूएल टेम्पलेट्स बनाए हैं जिन्हें एक PHP स्क्रिप्ट द्वारा संसाधित किया गया था जो बदले में "ट्रिगर कोड से जानकारी COLSN_NAME से पूछताछ" पर आधारित पूर्ण ट्रिगर परिभाषाओं को आउटपुट कर रहा था ... "हाँ, ट्रिगर कोड बहुत बड़ा था, लेकिन यह काम करता था! उम्मीद है कि थोड़ा मदद करता है =)

+2

आपके उत्तर के लिए धन्यवाद, हालांकि ट्रिगर्स का उपयोग करने का एकमात्र कारण यह है कि मुझे PHP को शामिल नहीं करना होगा - अगर मैंने PHP के साथ इस कार्यक्षमता को लागू करना चुना है तो यह प्रश्न मौजूद नहीं होगा। मेरे पास पहले से ही PHP में कोडित एक विशाल प्रणाली है और यदि मुझे वहां जाना है और कोड में ऑडिट लागू करना है तो यह आत्मघाती होगा। – Caballero

0

मैंने छाया तालिका बनाकर परियोजनाओं में से एक के लिए यह किया।यदि आप अपडेट के लाखों लोगों के साथ काम कर नहीं कर रहे हैं, इस

  • काम हो सकता है जब उपयोगकर्ता में लॉग करता है, सेट @user_id = {प्रयोक्ता आईडी में लॉग इन} अद्यतन से पहले पंक्ति कॉपी करने के लिए
  • मेज पर एक ट्रिगर बनाएं एक ही संरचना के साथ एक छाया तालिका में संशोधित किया जाना चाहिए (ध्यान दें कि छाया छाया में न ही प्राथमिक कुंजी हो सकती है और न ही अनन्य कुंजी)
  • छाया तालिका में अतिरिक्त कॉलम जोड़ें (संशोधित_बी, संशोधित_ऑन)
  • एक छोटा php बनाएं कॉलम के बीच अंतर दिखाने के लिए स्क्रिप्ट - इस तरह आप मौजूदा PHP कोड बेस
  • को स्पर्श नहीं करते हैं 0
  • अगर आप अपडेट की बहुत सारी के साथ काम कर और छाया तालिका छोटे रखना चाहते हैं, एक क्रॉन छाया तालिका पार्स और जो स्तंभ बदल की पहचान करने और केवल एक और तालिका में यह जानकारी स्टोर
संबंधित मुद्दे