क्या लेनदेन के अंदर कई डीडीएल स्टेटमेंट चलाने के लिए संभव है (SQL सर्वर के भीतर)?

Question

मुझे आश्चर्य है कि लेनदेन के अंदर कई डीडीएल विवरणों को चलाने के लिए संभव है या नहीं। मैं विशेष रूप से SQL सर्वर पर रूचि रखता हूं, भले ही अन्य डेटाबेस (ओरेकल, पोस्टग्रेएसक्यूएल कम से कम) के साथ उत्तर भी दिलचस्प हो।

मैं लेनदेन के अंदर बनाई गई तालिका के लिए कुछ "तालिका बनाएं" और "दृश्य बनाएं" कर रहा हूं और कुछ असंगतताएं प्रतीत होती हैं और मुझे आश्चर्य है कि लेनदेन के अंदर डीडीएल नहीं किया जाना चाहिए। ..

मैं शायद लेन-देन के बाहर ले जाने के DDL सकता है, लेकिन मैं इसके लिए कुछ संदर्भ प्राप्त करना चाहते हैं। मैं इतनी दूर क्या पाया है:

• MSDN पेज Isolation Levels in the Database Engine स्पष्ट रूप से है कि वहाँ क्या DDL संचालन एक स्पष्ट लेनदेन है कि स्नैपशॉट अलगाव के तहत चल रहा है में किया जा सकता पर प्रतिबंध है बताता है - लेकिन मैं स्नैपशॉट अलगाव का उपयोग नहीं और यह एक त्रुटि के रूप में परिणाम होना चाहिए।
  • इसका अर्थ यह हो सकता है कि डीडीएल संचालन अलग अलगाव स्तर के तहत एक स्पष्ट लेनदेन में प्रदर्शन किया जा सके? सीधे इस्तेमाल किया एसक्यूएल सर्वर के लिए इस वैध है भी -
• Oracle® Database Gateway for SQL Server User's Guide#DDL Statements कहा गया है कि केवल एक DDL बयान दिए गए लेन-देन में क्रियान्वित किया जा सकता?

ओरेकल के लिए:

• के भीतर ऐसा Unit testing DDL statements that need to be in a transaction सवाल यह कहा ओरेकल निहित है कि है एक DDL बयान के लिए प्रतिबद्ध? (भले ही कोई संदर्भ नहीं)

यदि यह कुछ मायने रखता है, तो मैं जावा के साथ जेटीडीएस जेडीबीसी ड्राइवर के माध्यम से ऐसा कर रहा हूं।

बीआरआर Touko

Answer 1

यह हो सकता है कि एमएस एसक्यूएल में, अंतर्निहित लेनदेन ट्रिगर कर रहे हैं जब DDL और DML बयान चलाए जा रहे हैं। आप इस बंद हो तो करता है यह सहायता, सेट IMPLICIT_TRANSACTIONS

संपादित का उपयोग करें: एक और संभावना - आप एक ही बैच में अन्य बयानों के साथ दृश्य बनाने के साथ नहीं जोड़ सकते। टेबल बनाएं ठीक है। आप गो के साथ अलग बैचों।

EDIT2: जब तक एक सौदे में एक से अधिक DDL उपयोग कर सकते हैं विभिन्न समूहों बनाने के लिए GO के साथ अलग कर दिया।

Answer 2

सामान्य मामले और IIRC के लिए, यह मान लेना DDL बयान व्यवहार कर रहे हैं सुरक्षित नहीं है।

कहना है कि, वहाँ कैसे स्कीमा परिवर्तन एक सौदे के भीतर बातचीत पर छूट के एक महान सौदा (यह मानते हुए यह बिल्कुल नहीं है) है। यह विक्रेता द्वारा या यहां तक ​​कि विशेष स्थापना द्वारा भी हो सकता है (यानी, डीबीए तक) मेरा मानना ​​है। तो कम से कम, एक डीबीएमएस का उपयोग यह न मानने के लिए करें कि अन्य लोग डीडीएल कथन का इलाज करेंगे।

संपादित करें: MySql एक डीबीएमएस जो सभी पर DDL लेनदेन का समर्थन नहीं करता का एक उदाहरण है।इसके अलावा, यदि आपके पास डेटाबेस प्रतिकृति/मिररिंग है तो आपको बहुत सावधान रहना होगा कि प्रतिकृति सेवा (साइबेस की प्रतिकृति मानक है, मान लीजिए या नहीं) वास्तव में डीडीएल कथन को दोहराएगी।

Answer 3

यदि आप फ्लाई (टेबल चर या अस्थायी तालिकाओं के अलावा) पर टेबल, दृश्य आदि बना रहे हैं, तो आपको वास्तव में अपने डिज़ाइन पर पुनर्विचार करने की आवश्यकता हो सकती है। यह सामान नहीं है जो सामान्य रूप से उपयोगकर्ता इंटरफ़ेस से होना चाहिए। भले ही आपको कुछ अनुकूलन की अनुमति देनी पड़े, फिर भी डीडीएल स्टेटमेंट्स लेनदेन संबंधी आवेषण/अपडेट/हटाए जाने के साथ ही नहीं हो रहा है। इन कार्यों को अलग करना कहीं बेहतर है।

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

इसके अलावा कुछ डीडीएल विवरण हमेशा बैच का पहला विवरण होना चाहिए। उस समय भी देखें जब आप उन्हें चला रहे हों।

Answer 4

मुझे पता है कि अधिकांश डेटाबेस में प्रतिबंध हैं, लेकिन पोस्टग्रेस नहीं है। आप लेनदेन में किसी भी संख्या तालिका निर्माण, कॉलम परिवर्तन और अनुक्रमणिका परिवर्तन चला सकते हैं, और परिवर्तन अन्य उपयोगकर्ता इकाई COMMIT सफल होने के लिए दृश्यमान नहीं हैं। इस तरह डेटाबेस होना चाहिए! :-)

SQL सर्वर के लिए आप लेनदेन के अंदर डीडीएल चला सकते हैं, लेकिन SQL Server does not version metadata, और लेनदेन करने से पहले अन्य लोगों के लिए परिवर्तन दिखाई देंगे। लेकिन some DDL statements can be rolled back if you are in a transaction, लेकिन जिनके लिए काम करते हैं और कौन से आपको कुछ परीक्षण चलाने की आवश्यकता नहीं होगी।