मैंने विभिन्न उदाहरणों में int/long के बजाय दशमलव का उपयोग देखा है। मैं बस यह समझने की कोशिश कर रहा हूं कि क्यों
ऐसा शायद इसलिए है क्योंकि .NET decimal और Oracle NUMBER नक्शा long . से थोड़ा बेहतर है और NUMBER और यह आपको अधिक लचीलापन भी देता है। यदि आप बाद के चरण में पैमाना . जोड़ें यदि आप पहले से ही decimal . का उपयोग करते हैं तो Oracle कॉलम में आपको डेटाटाइप बदलने की आवश्यकता नहीं होगी .
decimal निश्चित रूप से int . से धीमा है और long चूंकि बाद के दो हार्डवेयर में समर्थित हैं। उस ने कहा, आपको कोई फर्क करने के लिए कुछ गंभीर मात्रा में डेटा की कमी करनी होगी। मुझे अब भी लगता है कि आपको long . का इस्तेमाल करना चाहिए यदि आप यही काम कर रहे हैं और फिर आपको टेबल कॉलम परिभाषाओं को भी इसका प्रतिनिधित्व करने देना चाहिए। NUMBER(18,0) long . के लिए और इसी तरह।
कारण decimal नक्शा थोड़ा बेहतर है कि long 64 बिट और decimal है है (तरह का) 128 बिट।
.नेट
प्रकार:दशमलव
अनुमानित सीमा:±1.0 × 10^−28 से ±7.9 × 10^28
परिशुद्धता:28-29 महत्वपूर्ण अंकप्रकार:लंबा
सीमा:-9,223,372,036,854,775,808 से 9,223,372,036,854,775,807
परिशुद्धता:18 (उलोंग के लिए 19) महत्वपूर्ण अंक
ओरेकल
NUMBER डिफ़ॉल्ट रूप से 38 महत्वपूर्ण अंक और स्केल 0 (पूर्णांक)।
प्रकार:NUMBER
सीमा:+- 1 x 10^-130 से 9.99...9 x 10^125
परिशुद्धता:38 महत्वपूर्ण अंक
Microsoft समस्या और नोट्स से अवगत है
<ब्लॉकक्वॉट>यह डेटा प्रकार NUMBER(38) डेटा प्रकार के लिए एक उपनाम है, और इसे डिज़ाइन किया गया है ताकि OracleDataReader एक पूर्णांक मान के बजाय एक सिस्टम। दशमलव या OracleNumber लौटाए। .NETFramework डेटा प्रकार का उपयोग करने से ओवरफ़्लो हो सकता है।
इसके बारे में सोचें कि आपको वास्तव में BigInteger need की आवश्यकता है क्या NUMBER . के समान महत्वपूर्ण अंकों का प्रतिनिधित्व करने में सक्षम होने के लिए करने के लिए चूक। मैंने कभी किसी को ऐसा करते नहीं देखा और मुझे लगता है कि यह एक बहुत ही दुर्लभ आवश्यकता है। साथ ही BigInteger NUMBER . के बाद से अभी भी इसे नहीं काटेगा सकारात्मक और नकारात्मक अनंत का हो सकता है।
