एक MySQL डेटाबेस में मुद्रा मूल्यों को संग्रहीत करने के लिए सर्वश्रेष्ठ डेटा प्रकार


212

मुद्रा मूल्यों के लिए सबसे अच्छा एसक्यूएल डेटा प्रकार क्या है? मैं MySQL का उपयोग कर रहा हूं, लेकिन एक डेटाबेस स्वतंत्र प्रकार को पसंद करेगा।


जवाबों:


227

Decimal(19,4)आमतौर पर ज्यादातर मामलों में कुछ बहुत अच्छा काम करता है। आपके द्वारा संग्रहित किए जाने वाले नंबरों की जरूरतों को पूरा करने के लिए आप पैमाने और सटीकता को समायोजित कर सकते हैं। SQL सर्वर में भी, मैं moneyगैर-मानक के रूप में " " का उपयोग नहीं करता हूं ।


52
आकार के बारे में एक बिंदु: MSDN ( msdn.microsoft.com/en-us/library/ms187746.aspx ) के अनुसार , दशमलव (10,4) और दशमलव (19,4) दोनों में 9 बाइट्स का उपयोग किया जाता है, इसलिए पैमाने के उस अतिरिक्त 9 अंकों के लिए अच्छी तरह से वसंत।
एडम नोफ़्सिंगर

1
MSDN आलेख SQL सर्वर के बारे में है, लेकिन प्रश्न MySQL के बारे में है। (मुझे ऐसे डेवलपर्स मिले हैं जो सोचते हैं कि दोनों स्पष्ट होने के लिए समान हैं।)
cja

5
के (19,4)बजाय का उपयोग करने के लिए लाभ क्या है (19,2)?
२०:०२

1
मेरा लाभ यह था .. मुझे एक विशेष राशि के बराबर करने के लिए अपनी सभी तालिका पंक्तियों की आवश्यकता थी। मान लीजिए कि राशि $ 10.00 है। नई पंक्तियों के रूप में प्रत्येक पंक्ति राशि में बदलाव किए जाते हैं। यदि तालिका में 3 पंक्तियाँ हैं। 10/3 = 3.3333333333 ... लेकिन केवल 2 दशमलव के साथ उन्हें 3.33 के रूप में संग्रहीत किया जाता है। इसलिए जब आप उन योगों को जोड़ते हैं, तो 3.33 + 3.33 + 3.33 = 9.99। हमने एक पैसा खो दिया! एक बड़े डेटासेट पर और भी बुरा हो जाता है। 19,4 पर स्टोर करें और अपने कुल योग करें, फिर आउटपुट को 19,2 तक राउंड करें ..
रिक

49

केवल एक चीज जो आपको देखनी है, वह यह है कि यदि आप एक डेटाबेस से दूसरे डेटाबेस में जाते हैं, तो आप पा सकते हैं कि DECIMAL (19,4) और DECIMAL (19,4) का मतलब अलग-अलग चीजें हैं

( http://dev.mysql.com/doc/refman/5.1/en/preaches-math-decimal-bages.html )

    DBASE: 10,5 (10 पूर्णांक, 5 दशमलव)
    MYSQL: 15,5 (15 अंक, 10 पूर्णांक (15-5), 5 दशमलव)

लिंक अब मृत है, दुर्भाग्य से।
मार्को औरेलियो डेलेयू

1
@ MarcoAurélioDeleu - मैंने वेनबैक मशीन पर पेज को इंगित करने के लिए लिंक को बदल दिया है, इसलिए आप इसे 2009 में वापस देखा जा सकता है।
टोनी

17

यह भी महत्वपूर्ण है कि आपके गणना के लिए कितने दशमलव स्थानों की आवश्यकता है।

मैंने एक शेयर मूल्य एप्लिकेशन पर काम किया, जिसमें एक मिलियन शेयरों की कीमत की गणना की आवश्यकता थी। उद्धृत शेयर मूल्य को सटीकता के 7 अंकों में संग्रहीत किया जाना था।


7
यह एक अच्छा बिंदु है - विशेष रूप से वित्तीय ऐप्स में, "मूल्य" सबसे निश्चित रूप से "पैसा" नहीं लगाता है
माइक वुडहाउस

17

असफ की प्रतिक्रिया

निर्भर करता है कि आपको कितना पैसा मिला ...

लग रहा है, लेकिन वास्तव में यह खतरनाक है।

केवल आज हमारे पास एक मुद्दा था जहां एक रिकॉर्ड हमारी दर तालिका में डालने में विफल रहा, क्योंकि स्तंभों में से एक (सकल) को दशमलव (11,4) पर सेट किया गया है, और हमारे उत्पाद विभाग को सिर्फ कुछ अद्भुत रिसॉर्ट में कमरों के लिए एक अनुबंध मिला है बोरा बोरा में, जो प्रति रात कई मिलियन पैसिफिक फ्रैंच के लिए बेचते हैं ... कुछ ऐसा जो कभी भी एंटीकाटेड नहीं था जब डेटाबेस स्कीमा 10 साल पहले डिज़ाइन किया गया था।


2
यही कारण है कि मैंने दशमलव (19,4) की सिफारिश की। ओवरकिल की तरह ध्वनि हो सकती है, लेकिन आपको कभी नहीं पता होगा कि आपको उस क्षेत्र में वास्तव में बड़ी मात्रा में स्टोर करने की आवश्यकता होगी।
किबी

2
@ रिबन: मैं आज तक हमारी आवश्यकताओं के लिए आपके साथ सहमत नहीं होता। (6 साल (11,4) के लिए पूरी तरह से ठीक था ...)
स्कॉट फर्ग्यूसन

@ किबी यह ऐसा लगता है जैसे 640 Kb मेम :) :)
निकिता बोसिक

13

लेखांकन अनुप्रयोगों के लिए पूर्णांक के रूप में मूल्यों को संग्रहीत करना बहुत आम है (कुछ तो यहां तक ​​कहते हैं कि यह एकमात्र तरीका है)। एक विचार प्राप्त करने के लिए, लेन-देन की राशि लें (मान लें कि $ 100.23) और एकाधिक 100, 1000, 10000, आदि द्वारा आपको सटीकता की आवश्यकता होती है। तो अगर आपको केवल सेंट को स्टोर करने की आवश्यकता है और सुरक्षित रूप से ऊपर या नीचे गोल कर सकते हैं, तो बस 100 से गुणा करें। मेरे उदाहरण में, यह स्टोर करने के लिए पूर्णांक के रूप में 10023 बना देगा। आप डेटाबेस में जगह बचाएंगे और दो पूर्णांक की तुलना दो झूलों की तुलना में बहुत आसान है। मेरी $ 0.02।


आप 6.125 (6 1/8) को कैसे स्टोर करते हैं?
पीटरटॉइथर्ड

मुझे लगता है कि वह इसे एक पूर्णांक 6125 के रूप में संग्रहीत करेगा।
जिमी नट

2
इससे बेहतर कैसे होगा DECIMAL? आपको हमेशा उचित समय पर डॉलर में पेन, मिल या मिलरे का अनुवाद करने के बारे में बहुत सावधान रहने की आवश्यकता होगी ।

मैंने पढ़ा है कि प्रदर्शन आमतौर पर INTSQL की तुलना में तेज है, यहां तक ​​कि MySQL के नवीनतम संस्करणों में भी। जब आप इन मूल्यों को PHP या किसी चीज़ में लाना चाहते हैं और मूल्यों की तुलना करना आसान हो जाता है।
डेन बेंडिक्सन

9

सुपर देर से प्रवेश लेकिन GAAP अंगूठे का एक अच्छा नियम है ..

यदि आपके आवेदन को एक ट्रिलियन तक के मानों को संभालने की आवश्यकता है, तो यह काम करना चाहिए: 13,2 यदि आपको GAAP (आमतौर पर स्वीकृत लेखा सिद्धांतों) का अनुपालन करने की आवश्यकता है तो उपयोग करें: 13,4

आमतौर पर आपको आउटपुट को राउंड करने से पहले 13,4 पर अपने मनी वैल्यू को 13,2 पर समिट करना चाहिए।

स्रोत: MySQL में मौद्रिक मूल्य को संग्रहीत करने के लिए सर्वश्रेष्ठ डेटाटाइप


5

आप DECIMAL(19,2)अपने सभी मौद्रिक मूल्यों के लिए डिफ़ॉल्ट रूप से कुछ का उपयोग कर सकते हैं , लेकिन यदि आप कभी भी केवल 1,000 डॉलर से कम मूल्य के स्टोर करेंगे, तो यह केवल मूल्यवान डेटाबेस स्थान की बर्बादी होगी।

अधिकांश कार्यान्वयनों के लिए, DECIMAL(N,2)पर्याप्त होगा, जहाँ उस मान का Nकम से कम अंकों की संख्या .सबसे बड़ी राशि है जो आप उस क्षेत्र में संग्रहीत किए जाने की अपेक्षा करते हैं + 5। इसलिए यदि आप कभी भी 999999.99 से अधिक के किसी भी मूल्य को स्टोर करने की उम्मीद नहीं करते हैं, तो यह DECIMAL(11,2)पर्याप्त से अधिक होना चाहिए (जब तक कि उम्मीदें बदल न जाएं)।

यदि आप जीएएपी के अनुरूप होना चाहते हैं , तो आप उस क्षेत्र में जा सकते हैं DECIMAL(N,4), जहां मूल्य का Nकम से कम अंकों की संख्या .सबसे बड़ी राशि से पहले है जिसे आप उस क्षेत्र में संग्रहीत किए जाने की अपेक्षा करते हैं + 7


3

यह डेटा की प्रकृति पर निर्भर करता है। आपको पहले से इस पर चिंतन करने की आवश्यकता है।

मेरा मामला

  • दशमलव (13,4) ने पैसे के लेनदेन को रिकॉर्ड करने के लिए अहस्ताक्षरित किया
    • भंडारण कुशल (वैसे भी दशमलव बिंदु के प्रत्येक पक्ष के लिए 4 बाइट्स) 1
    • जीएएपी अनुरूप
  • दशमलव (19,4) समुच्चय के लिए अहस्ताक्षरित है
    • हमें कई बहु-अरब लेनदेन के योग के लिए अधिक स्थान की आवश्यकता है
    • एमएस मुद्रा डेटा प्रकार के साथ अर्ध-अनुपालन 2 चोट नहीं करेगा
    • यह प्रति रिकॉर्ड अधिक स्थान लेगा (11 बाइट्स - 7 बाएं और 4 दाएं), लेकिन यह ठीक है क्योंकि कुल योग 1 के लिए कम रिकॉर्ड हैं
  • विनिमय दरों के लिए दशमलव (10,5)
    • वे आम तौर पर 5 अंकों के साथ उद्धृत किए जाते हैं ताकि आप 1.2345 और 12.345 जैसे मान पा सकें लेकिन 12345.67890 नहीं
    • यह व्यापक सम्मेलन है, लेकिन एक संहिताबद्ध मानक नहीं (कम से कम मेरे त्वरित खोज ज्ञान के लिए)
    • आप इसे एक ही भंडारण के साथ दशमलव (18,9) बना सकते हैं, लेकिन डेटाटाइप प्रतिबंध मूल्यवान अंतर्निहित सत्यापन तंत्र हैं

क्यों (एम, 4)?

  • ऐसी मुद्राएं हैं जो एक हजार पैसे में विभाजित होती हैं
  • 4 महत्वपूर्ण दशमलव स्थानों 3 , 4 के साथ व्यक्त किए गए "Unidad de Fermento", "CLF" जैसे पैसे समकक्ष हैं
  • यह GAAP अनुपालन है

अदला - बदली

  • निम्न परिशुद्धता:
    • कम भंडारण लागत
    • जल्दी गणना
    • कम गणना त्रुटि जोखिम
    • जल्दी बैकअप और बहाल
  • उच्च परिशुद्धता:
    • भविष्य की अनुकूलता (संख्या बढ़ने के लिए)
    • विकास समय की बचत (सीमाएं पूरी होने पर आपको आधी प्रणाली का पुनर्निर्माण नहीं करना पड़ेगा)
    • अपर्याप्त भंडारण परिशुद्धता के कारण उत्पादन विफलता का कम जोखिम

संगत चरम

हालाँकि MySQL आपको दशमलव (65,30) का उपयोग करने देता है, 31 पैमाने के लिए और 30 सटीकता के लिए हमारी सीमा लगती है यदि हम हस्तांतरण को खुला छोड़ना चाहते हैं।

सबसे आम RDBMS में अधिकतम पैमाने और सटीकता:

            परिशुद्धता स्केल
ओरेकल 31 31
टी-एसक्यूएल 38 38
MySQL 65 30
PostgreSQL 131072 16383

6 , 7 , 8 , 9

उचित चरम

  1. क्यों (27,4)?
    • आप कभी नहीं जानते कि सिस्टम को जिम्बाब्वे डॉलर को कब स्टोर करना है

सितंबर 2015 जिम्बाब्वे की सरकार ने कहा कि वह 1 मिलियन अमरीकी डालर की दर से जिम्बाब्वे डॉलर का भुगतान करेगी, जो कि 1 बिलियन अमरीकी डालर से 35 बिलियन अमरीकी डॉलर प्रति 5 मिलियन डॉलर की दर पर होगा।

हम कहते हैं "हाँ, यकीन है ... मुझे उस पागल आंकड़े की आवश्यकता नहीं होगी"। खैर, जिम्बाब्वे भी ऐसा ही कहता था। बहुत पहले की बात नहीं है।

आइए कल्पना करें कि आपको ज़िम्बाब्वे डॉलर में 1 मिलियन अमरीकी डालर का लेनदेन रिकॉर्ड करने की आवश्यकता है (शायद आज की संभावना नहीं है, लेकिन कौन जानता है कि यह अब से 10 वर्षों में कैसा लगेगा?)।

  1. (1 mln USD) * (35 क्वाड्रिलियन ZWL) = (10 ^ 6) * (35 * 10 ^ 15) = 35 * 10 ^ 21
  2. ज़रुरत है:
    • "35" स्टोर करने के लिए 2 अंक
    • शून्य को संग्रहीत करने के लिए 21 अंक
    • दशमलव बिंदु के दाईं ओर 4 अंक
  3. यह दशमलव (27,4) बनाता है जिसकी लागत प्रत्येक प्रविष्टि के लिए 15 बाइट्स होती है
  4. हम बिना किसी खर्च के बाईं ओर एक और अंक जोड़ सकते हैं - हमारे पास 15 बाइट्स के लिए दशमलव (28,4) है
  5. अब हम जिम्बाब्वे डॉलर में व्यक्त 10 मिलियन अमरीकी डालर के लेनदेन को स्टोर कर सकते हैं, या हिपरिनफ्लेशन की एक और हड़ताल से सुरक्षित कर सकते हैं, जो कि संभवतः होगा।

0

हालांकि यह देर हो सकती है, लेकिन यह किसी और के लिए उपयोगी होगा। मेरे अनुभव और अनुसंधान से मुझे दशमलव (19, 6) को जानने और स्वीकार करने के लिए आया है। यह तब है जब php और mysql के साथ काम कर रहा है। बड़ी मात्रा में धन और विनिमय दर के साथ काम करते समय

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.