मल्टी-उपयोगकर्ता सास एप्लिकेशन में अनुक्रमिक संख्याएं उत्पन्न करना

Question

लोग एक विशिष्ट सास एप्लिकेशन में किसी विशेष उपयोगकर्ता के लिए auto_incrementing पूर्णांक कैसे उत्पन्न करते हैं?

उदाहरण के लिए, किसी विशेष उपयोगकर्ता के लिए सभी चालानों के लिए चालान संख्या auto_incrementing होना चाहिए और 1 से शुरू होना चाहिए। रेल आईडी आईडी फ़ील्ड का उपयोग इस मामले में नहीं किया जा सकता है, क्योंकि यह सभी उपयोगकर्ताओं के बीच साझा किया जाता है।

मेरे सिर के ऊपर से, मैं उपयोगकर्ता के सभी चालानों को गिन सकता हूं, और फिर 1 जोड़ सकता हूं, लेकिन क्या किसी को किसी भी बेहतर समाधान के बारे में पता है?

Answer 1

कोई संबंध डेटाबेस के लिए विशिष्ट समाधान की तरह

user_invoice_numbers (user_id int primary key clustered, last_id int) 

एक मेज और एक संग्रहीत प्रक्रिया या की तरह

update user_invoice_numbers set last_id = last_id + 1 where user_id = @user_id 
select last_id from user_invoice_numbers where user_id = @user_id 

एक SQL क्वेरी यदि प्रत्येक उपयोगकर्ता में कुछ है यह उपयोगकर्ताओं के लिए काम करेंगे (हो सकता है साथ ही लेनदेन चलाना) लेकिन कंपनियों के लिए काम नहीं करेगा (उदाहरण के लिए जब आपको company_invoice_numbers की आवश्यकता होती है) क्योंकि एक ही कंपनी के अंदर विभिन्न उपयोगकर्ताओं के लेन-देन एक-दूसरे को अवरुद्ध कर सकते हैं और इस तालिका में एक प्रदर्शन बाधा होगी।

आपको सबसे महत्वपूर्ण कार्यात्मक आवश्यकता की जांच करनी चाहिए क्या आपके सिस्टम को इनवॉइस नंबरिंग में अंतर होने की अनुमति है या नहीं है। जब आप मानक auto_increment का उपयोग करते हैं, तो आप अंतराल की अनुमति देते हैं, क्योंकि अधिकांश डेटाबेस में मुझे पता है, जब आप रोलबैक लेनदेन करते हैं, तो बढ़ी हुई संख्या को वापस नहीं किया जाएगा। इसे ध्यान में रखते हुए, आप निम्नलिखित दिशानिर्देशों में से एक का उपयोग करके प्रदर्शन में सुधार कर सकते हैं

1) लंबे समय से चल रहे लेनदेन से नई संख्या प्राप्त करने के लिए उपयोग की जाने वाली प्रक्रिया को छोड़ दें। मान लीजिए कि चालान प्रक्रिया में डालें जटिल सर्वर-साइड तर्क के साथ एक लंबा चल रहा लेनदेन है। इस मामले में आप पहले एक नई आईडी प्राप्त करते हैं, और फिर, अलग लेनदेन में नए चालान डालें। यदि अंतिम लेनदेन वापस लुढ़का जाएगा, तो ऑटो-नंबर कम नहीं होगा।लेकिन user_invoice_numbers लंबे समय तक लॉक नहीं होंगे, इसलिए बहुत से उपयोगकर्ता एक ही समय में चालान डाल सकते हैं

2) प्रत्येक उपयोगकर्ता के लिए अंतिम आईडी वाले डेटा को संग्रहीत करने के लिए पारंपरिक लेनदेन डेटाबेस का उपयोग न करें। जब आपको चाबियों और मानों की सरल सूची बनाए रखने की आवश्यकता होती है तो वहां बहुत छोटे लेकिन तेज़ डेटाबेस इंजन होते हैं जो आपके लिए यह काम कर सकते हैं। List of Key/Value databases। शायद memcached सबसे लोकप्रिय है। अतीत में, मैंने उन परियोजनाओं को देखा जहां सरल कुंजी/मूल्य भंडार जहां विंडोज रजिस्ट्री या यहां तक ​​कि एक फ़ाइल सिस्टम का उपयोग करके कार्यान्वित किया गया था। एक निर्देशिका थी जहां प्रत्येक फ़ाइल का नाम कुंजी था और प्रत्येक फ़ाइल के अंदर अंतिम आईडी थी। और एसक्यूएल टेबल का उपयोग करते हुए यह मोटा समाधान अभी भी बेहतर था, क्योंकि ताले जारी किए गए और बहुत जल्दी जारी किए गए और लेनदेन के दायरे में शामिल नहीं थे।

ठीक है, अगर आपके प्रोजेक्ट के लिए ऑप्टिमाइज़ेशन के लिए मेरा प्रस्ताव अधिक जटिल लगता है, तो इस बारे में भूल जाओ, जब तक आप वास्तव में प्रदर्शन समस्याओं में भाग नहीं लेते। अधिकांश परियोजनाओं में एक अतिरिक्त तालिका के साथ सरल विधि बहुत तेज काम करेगा।

Answer 2

यह सुनिश्चित नहीं है कि यह सबसे अच्छा समाधान है, लेकिन आप उपयोगकर्ता पर अंतिम चालान आईडी स्टोर कर सकते हैं और उसके बाद उस उपयोगकर्ता के लिए एक नया चालान बनाते समय अगली आईडी निर्धारित करने के लिए इसका उपयोग कर सकते हैं। लेकिन इस सरल समाधान में अखंडता के साथ समस्या हो सकती है, सावधान रहना होगा।

Answer 3

आप अपने "उपयोगकर्ता" तालिका से जुड़े एक और तालिका को पेश कर सकते हैं जो उपयोगकर्ता के लिए सबसे हालिया चालान संख्या ट्रैक करता है। हालांकि, इस मान को पढ़ने के परिणामस्वरूप डेटाबेस क्वेरी होगी, इसलिए आप उपयोगकर्ता के चालान की गिनती भी प्राप्त कर सकते हैं और जैसा कि आपने सुझाव दिया है, एक जोड़ सकते हैं। किसी भी तरह से, यह एक डेटाबेस हिट है।

Answer 4

यदि चालान संख्या प्रत्येक उपयोगकर्ता/ग्राहक के लिए स्वतंत्र हैं तो ऐसा लगता है कि उपयोगकर्ता के साथ जुड़े कुछ लगातार स्टोर (जैसे डीबी रिकॉर्ड) में "अंतिम चालान" फ़ील्ड बहुत अपरिहार्य है। हालांकि इससे "नवीनतम" संख्या के लिए कुछ विवाद हो सकता है।

क्या इससे कोई फर्क पड़ता है कि क्या हम उपयोगकर्ता चालान 1, 2, 3 और 5 भेजते हैं, और कभी उन्हें इनवॉइस 4 नहीं भेजते हैं? यदि आप थोड़ी आवश्यकता को आराम कर सकते हैं।

यदि आवश्यकता वास्तव में "प्रत्येक चालान संख्या अद्वितीय होनी चाहिए" तो हम सभी सामान्य आईडी उत्पन्न करने वाली चाल देख सकते हैं, और ये काफी कुशल हो सकते हैं।

यह सुनिश्चित करना कि संख्याएं अनुक्रमिक हैं जटिलता में जोड़ती हैं, क्या यह व्यावसायिक लाभ में जोड़ती है?

Answer 5

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

Answer 6

मैं सिर्फ एक मणि है कि अपनी जरूरत को हल करना चाहिए (कुछ साल देर से कभी नहीं की तुलना में बेहतर है!) :)

https://github.com/alisyed/sequenceid/