डेटा प्रकारों को एक बहुत बड़ी टेबल पर संक्षिप्त करना

सबसे पहले, ऐसा करने के लिए धन्यवाद। यह इतनी स्पष्ट जीत है कि बहुतों को इसमें अधिक मूल्य नहीं दिखाई देगा, लेकिन यह इसके लायक होगा :)। दुनिया को इतना हल्का बनाना।

IsActive . के संबंध में एक बूलियन होने के नाते। मेरा अनुमान है कि आप इसे BIT बनाने की सोच रहे हैं खेत। यह जाने का रास्ता हो सकता है, लेकिन कभी-कभी TINYINT के साथ जाना बेहतर होता है क्योंकि 2 से अधिक राज्यों में अर्थ के विस्तार की संभावना है। किस स्थिति में यह वास्तव में StatusID . से अधिक हो जाता है . आमतौर पर यह सक्रिय . के रूप में सरलता से शुरू होने वाली किसी चीज़ का मामला होता है / निष्क्रिय , लेकिन बाद में शायद हटाया गया और/या अन्य। आकार के दृष्टिकोण से, TINYINT हमेशा 1 बाइट होता है। दूसरी ओर, BIT 1 बाइट अधिकतम 8 BIT के लिए है फ़ील्ड . मतलब, एक BIT फ़ील्ड 1 बाइट है, 2 BIT फ़ील्ड भी एक बाइट है, और इसी तरह 8 BIT . तक फ़ील्ड को एक बाइट में संग्रहीत किया जा रहा है। इसलिए, BIT . चुनने से कोई जगह बचत नहीं होती है TINYINT से अधिक जब तालिका में केवल 1 BIT हो खेत। बस कुछ विचार करना है।

जैसा कि आपने देखा, एक बड़ी तालिका के लिए ALTER TABLE करना थोड़ा अधिक है। एक विकल्प, हालांकि बढ़िया नहीं है, एक NOT NULL add जोड़ना है फ़ील्ड--Number_1new --एक DEFAULT के साथ मान (यह डिफ़ॉल्ट के कारण तात्कालिक होगा, कम से कम SQL 2012 से शुरू होगा) कि उनमें से कोई भी स्वाभाविक रूप से नहीं होगा (उदाहरण के लिए 255), और फिर धीरे-धीरे मानों को एक लूप में माइग्रेट कर रहा है, जैसा कि:

UPDATE TOP (5000) tab
SET tab.Number_1new = tab.Number_1
FROM [table] tab
WHERE tab.Number_1new = 255;

और जब यह हो जाए तो करें:

sp_rename 'table.Number_1', 'Number_1old', 'COLUMN';
sp_rename 'table.Number_1new', 'Number_1', 'COLUMN';

बेशक, इसे एक लेनदेन में लपेटना सबसे अच्छा है, और यह एक कोशिश/पकड़ में लपेटा गया है। जब संबंधित कोड को अपडेट कर दिया गया है और सब कुछ परीक्षण किया गया है और डेटा अच्छा दिखता है, तो आप Number_1old को छोड़ सकते हैं कॉलम।

हालांकि, मुझे जो सबसे अच्छा तरीका मिला है वह है एक नई तालिका बनाना, धीरे-धीरे डेटा को स्थानांतरित करना, फिर उसी समय टेबल और कोड को स्वैप करना। मैंने SQL सर्वर सेंट्रल पर एक लेख में चरणों का विवरण दिया है:100 मिलियन पंक्ति का पुनर्गठन (या अधिक) सेकंड में टेबल्स। एसआरएसली! (मुफ्त पंजीकरण आवश्यक)। यदि उस लेख तक पहुंचने में कोई समस्या आती है, तो यहां मूल चरण दिए गए हैं:

1. आदर्श संरचना के साथ एक नई तालिका बनाएं--[tableNew]। यदि आप एंटरप्राइज़ संस्करण पर हैं, तो ROW या PAGE संपीड़न को सक्षम करने पर विचार करें क्योंकि वे कभी-कभी मदद कर सकते हैं। लेकिन कृपया पहले कुछ शोध करें क्योंकि कुछ स्थितियाँ ऐसी होती हैं जब उनका नकारात्मक प्रभाव पड़ता है। संभावित बचत का अनुमान लगाने में मदद करने के लिए एमएसडीएन पर प्रलेखन है जो आपको इसे समझने में मदद करता है और साथ ही कुछ टूल्स भी है। लेकिन अगर आप कंप्रेशन को सक्षम करते हैं, तो भी मैं उस क्रिया को उस प्रोजेक्ट को बदलने के रूप में नहीं देखूंगा जो आप यहां कर रहे हैं।
2. एक ट्रिगर जोड़ें AFTER UPDATE, DELETE परिवर्तनों को सिंक में रखने के लिए [टेबल] पर (लेकिन नई पंक्तियों के बारे में चिंता करने की कोई आवश्यकता नहीं है)
3. एक SQL एजेंट कार्य बनाएँ जो बैचों में अनुपलब्ध पंक्तियों पर ले जाए। इसे एक लूप में करें जो INSERT INTO [tableNew] (Columns) SELECT TOP (n) Columns FROM [table] WHERE ?? ORDER BY ??
4. WHERE और ORDER BY खंड स्थिति पर निर्भर करते हैं। उन्हें संकुल सूचकांक का सर्वोत्तम उपयोग करने के लिए तैयार किया जाना चाहिए। यदि नई तालिका का संकुल सूचकांक संरचनात्मक रूप से पुरानी/वर्तमान तालिका के समान है, तो प्रत्येक लूप की शुरुआत में आप [tableNew] से MAX([id]) प्राप्त कर सकते हैं और इसका उपयोग WHERE table.[id] > @MaxIdInTableNew ORDER BY table.[id] ।
5. नई तालिका बनाएं, वर्तमान तालिका पर ट्रिगर करें, और पूर्ण कट-ओवर करने से एक सप्ताह पहले SQL एजेंट कार्य करें। आपकी स्थिति के आधार पर वह समय-सीमा बदल सकती है, लेकिन बस खुद को भरपूर समय देना सुनिश्चित करें। काम के लिए माइग्रेटिंग पंक्तियों को समाप्त करना कहीं बेहतर है और एक बार में केवल कुछ ही ट्रिकलिंग होती है, जैसा कि रिलीज़ शुरू होने वाला है, पूर्ण सेट के 100k शर्मीले होने के विपरीत।
6. यदि योजना अन्य संबंधित तालिकाओं को स्थानांतरित करने की है (दो FK के लिए PK संदर्भ जिन्हें आप INT में बदलना चाहते हैं s), फिर उन क्षेत्रों को यहां INT बनाएं अभी और केवल एफके को तब तक न जोड़ें जब तक कि उन अन्य तालिकाओं को आईएनटी फ़ील्ड को उनके पीके के रूप में माइग्रेट नहीं किया जाता है। आप केवल FK फ़ील्ड के लिए यह परिवर्तन करने के लिए इस तालिका को फिर से बनाना नहीं चाहते हैं।
7. कट-ओवर के दौरान (जाहिर तौर पर TRY / CATCH में):
   1. ट्रान शुरू करें
   2. यह सुनिश्चित करने के लिए कि सब कुछ स्थानांतरित हो गया है, दोनों तालिकाओं पर अंतिम पंक्ति गणना करें (यह सुनिश्चित करने के लिए कि ट्रिगर ने अपडेट किया और अपेक्षित रूप से हटा दिया, यह सुनिश्चित करने के लिए रिलीज से पहले पंक्तियों की जांच करना चाहते हैं)
   3. वर्तमान तालिका का नाम बदलकर "पुराना" कर दें
   4. "नई" तालिका का नाम बदलें ताकि "नया" न हो
   5. एसक्यूएल एजेंट की नौकरी छोड़ें (या कम से कम इसे अक्षम करें)
   6. नाम बदलें और आश्रित वस्तुओं जैसे कि बाधाएं, आदि
   7. कमिट