SQL सर्वर दशमलव (9, 0) बनाम INT

Question

हमारे ग्राहकों DECIMAL(18,0)में से एक अपने SQL Server 2008R2 डेटाबेस में डेटाटाइप कुछ कॉलम के लिए उपयोग करता है। क्योंकि कॉलम काफी धीरे-धीरे बढ़ता है, उसने हाल ही में DECIMAL(5,0)कुछ संग्रहण को पुनः प्राप्त करने के लिए डेटाटाइप को बदलने का प्रस्ताव दिया ।

MSDN लाइब्रेरी के अनुसार , DECIMAL(5,0)डेटाटाइप का संग्रहण स्थान, डेटाटाइप की तरह DECIMAL(9,0), 5 बाइट्स है। INT1 बाइट छोटा है, लेकिन -99,999 के बजाय 99,999 में DECIMAL(5,0)स्टोर कर सकता है, जो -2 ^ 31 से 2 ^ 31 की रेंज में सब कुछ स्टोर कर सकता है। यहां तक ​​कि सबसे बड़ा DECIMALजो 5 बाइट्स में फिट बैठता है ( DECIMAL(9,0)) केवल पूर्णांकों को रेंज में -999,999,999 में 999,999,999 में स्टोर कर सकता है (जो INT4 बाइट्स में रेंज ऑफर के आधे से कम है )।

मैं दो का उपयोग कर के "लाभ" के बारे में सोच सकते हैं DECIMALसे अधिक INT:

• अधिक भंडारण स्थान का उपयोग किए बिना, पैमाने को बाद में जोड़ने की क्षमता
• डेटा प्रकार में बदलाव के बिना, 38 अंकों तक सटीकता को स्केल करने की क्षमता

लेकिन ये मेरी राय में वास्तविक लाभ नहीं हैं:

• पूर्णांकों में स्केल जोड़ना केवल बहुत कम मामलों में समझ में आता है (ज्यादातर मामलों में जहां पैमाने पर फर्क पड़ता है, इसे पहले भी जोड़ा जा सकता है)
• SQL सर्वर हर सटीक / स्केल संयोजन को एक अलग डेटा प्रकार के रूप में देखता है, इसलिए सटीक या स्केल को बढ़ाते समय डेटाटाइप को अकेला नहीं छोड़ा जाता है।

यह मुझे आश्चर्यचकित करता है: DECIMAL(5,0)पूर्णांक के लिए डेटाटाइप का अतिरिक्त लाभ क्या है ?

Comments

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

— dezso

IMO, यदि आपको यह सुनिश्चित करने की आवश्यकता है कि कॉलम मान एक सीमा के भीतर आते हैं, तो एक चेक बाधा का उपयोग करें। मुझे लगता है कि भविष्य में भिन्नात्मक मूल्यों की आवश्यकता वाले इस स्तंभ की संभावना होने पर ही यहाँ पर विचार किया जाएगा।

— जॉन सीगल

यदि वे भंडारण स्थान के बारे में चिंतित हैं, तो वे इसके मुकाबले संपीड़न का उपयोग करने के लिए बेहतर अनुकूल हैं। Int / bigint के बजाय दशमलव (x, 0) का उपयोग करने के लिए कोई ठोस लाभ नहीं है।

— रॉबर्ट एल डेविस

decimal(x,0)एक पूर्णांक प्रकार के बीच एक और अंतर खुद को अंकगणितीय विभाजन में दर्शाता है। यदि आप एक इंट को एक अंतर से विभाजित करते हैं, तो आपको एक इंट मिलता है। यदि आप एक दशमलव (x, 0) को एक इंट से विभाजित करते हैं, तो आपको एक दशमलव (x + 6,6) मिलता है।

— एंड्री एम

@AndriyM, मुझे लगता है कि यह सबसे बड़ा लाभ है। इसे एक टिप्पणी के बजाय एक उत्तर में वापस लाएं और मैं इसे उत्तर के रूप में चिह्नित करूंगा।

— १२

Answer 1

मैं मानता हूं कि जब तक आप DECIMAL (9, 0) बनाम INT या DECIMAL (18, 0) बनाम BIGINT की तुलना कर रहे हैं , भंडारण स्थान के संदर्भ में कोई वास्तविक लाभ नहीं हैं । (एक ही बाइट के भीतर।)

प्रसंस्करण के संदर्भ में, @Andriy का कहना है कि DECIMAL स्वाभाविक रूप से एक प्रकार में विभाजित हो जाएगा, जो भिन्नात्मक भाग को नहीं खोता है, यदि यह आपके लिए महत्वपूर्ण है।

दूसरी ओर, देशी INT प्रकार के साथ काम करना एक संख्यात्मक दृष्टिकोण से बहुत तेज़ है यदि आप बहुत सारे SUM () s या तुलना (जैसे मानों पर खोज) कर रहे हैं क्योंकि वे CPU द्वारा अधिक कुशलता से पाइपलाइन किए गए हैं। एक अंतर तुलना दो असेंबली ऑपकोड (MOV, CMP) है, लेकिन किसी भी दशमलव तुलना कई, कई और अधिक होगी।

Comments

आपका उत्तर समझ में आता है, लेकिन एक प्रोसेसर को डेटाैटिप्स का कोई ज्ञान नहीं है। तो 4 बाइट्स के एक डेटाटाइप की तुलना 4 बाइट्स के एक और डेटाटाइप के रूप में तेजी से की जाती है। क्या आप दिखा सकते हैं (एक दोहराने योग्य परीक्षण के साथ, उदाहरण के लिए) कि एक के DECIMAL(9, 0)बजाय का उपयोग करने में एक प्रदर्शन हिट है INT?

— vstrien

मुझे लगा कि मैं कर सकता हूं, लेकिन मैं स्वीकार करूंगा कि मेरे परीक्षण अनिर्णायक हैं। शायद पूर्णांक गणित में समस्या को कम करने के लिए एसक्यूएल एक अनुकूलन कर रहा है। मेरा परीक्षण किया गया: `- मेरी तुलना SET @StartTime = SYSDATETIME () WHILE (@CunderINT <@SizeINT) SET @CunderINT = @CunderINT + 1 प्रिंट 'INT ने' CONVERT (VARCHAR (20), DatedIFF (मिलीसेकंड, @StartTime) लिया। , SYSDATETIME ())) + 'मिलीसेकंड' --Decimal SET @StartTime = SYSDATETIME () WHILE (@CounterDEC <@SizeDEC) SET @CounterDEC = @CounterDEC + 1 PRINT 'DEC ने' + CONVERT (VARCHAR (20, DIFF) लिया। (मिलीसेकंड, @StartTime, SYSDATETIME ())) + 'मिलीसेकंड' `

— क्रिस चुब

मुझे लगता है कि SQL सर्वर वास्तव में कुछ का अनुकूलन करता है। अनुकूलन के बावजूद DECIMALअभी भी कुछ हद तक अधिक समय लगता है (कम से कम मेरे विकास प्रणाली पर)। 51 एमएस DEC बनाम 46 एमएस INT के आसपास 10 परीक्षणों के एक रन में।

— vstrien

Answer 2

ऐसा लग रहा है भंडारण स्थान के संदर्भ में कोई लाभ नहीं होगा ।

यदि आप ग्राहक से चिंतित हैं कि आप मान 2 ^ 32-1 (अधिकतम सकारात्मक मूल्य पूर्णांक स्टोर कर सकते हैं) से बड़ा होगा, तो आपको बिगआईंट पर जाने पर विचार करना चाहिए - 64 बिट्स ( 8 बाइट्स) के साथ ।