डेटाबेस में बिट मास्क का उपयोग करने के फायदे और नुकसान

Question

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

Comments

डेटाबेस को बिट मास्क आंतरिक रूप से बनाने और बिट्स को आपके लिए अलग कॉलम के रूप में प्रस्तुत करने के लिए अधिक समझदारी हो सकती है। आपकी आवश्यकताएं बदल सकती हैं।

— साइमन रिक्टर

यदि आप जॉइन का उपयोग नहीं करते हैं तो आप अपने रिलेशनल डेटाबेस का उपयोग उस तरह से नहीं कर रहे हैं जैसा कि इसका इरादा है।

— पीटर बी

Answer 1

मैं एक एप्लिकेशन के साथ काम करता हूं जो उपयोगकर्ता भूमिका असाइनमेंट को संग्रहीत करने के लिए बिटमास्क का उपयोग करता है। यह बट में दर्द है। यदि यह मुझे पक्षपाती बनाता है, तो दोषी ठहराया जाता है।

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

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

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

इसके खिलाफ मेरा अंतिम तर्क अन्य डेवलपर्स के लिए सादगी होगा। आपके पास उपयोगकर्ता, भूमिकाएं और असाइनमेंट हैं। यह कई-से-कई संबंध सेट है (क्योंकि एक से अधिक संबंध हैं) जो इतना सामान्य है, इसे प्रबंधित करना आसान होना चाहिए। यह सिर्फ CRUD सामान है।

Comments

एक रिलेशनल डेटाबेस बिटमेस्क के लिए सबसे खराब जगह है। भंडारण लागत अब इतनी बुरी नहीं है कि कुछ जोड़ और एक अतिरिक्त तालिका आपको तोड़ देनी चाहिए। यह निश्चित रूप से कारण के लिए सब कुछ कठिन बनाता है। डेटाबेस में बिट्स (1/0) के रूप में अनुमतियों को अपनी तालिका में संग्रहीत करें और उन्हें झंडे के साथ कोड में प्रतिनिधित्व करें। बहुत उपयुक्त और संभव लगता है। डेवलपर्स को साधारण झंडे मिलते हैं और डीबीए में सामान्यीकृत टेबल होते हैं। सब खुश हैं।

— मैक मैकमोहन

सहमत, मैं एक एप्लिकेशन का समर्थन करता था जो अपने डेटाबेस में उपयोगकर्ता भूमिकाओं और विशेषाधिकारों के लिए बिट मास्क का उपयोग करता था। यह एक दु: स्वप्न था। एक 32 बिट इंट का उपयोग करते हुए, हम बिट्स से बाहर भाग गए, इसलिए किसी को अधिक बिट मास्क जोड़ने का बहुत अच्छा विचार था , और फिर ओवरलैप के साथ, इसलिए एक कॉलम में बिट 4 का मतलब इस अन्य कॉलम में बिट 8 था, और वे सिंक से बाहर हो गए। ऐ दिल है मुश्किल। यह अनुक्रमणिका के लिए कठिन था क्योंकि अनुक्रमणिका असतत स्तंभ मानों को संग्रहीत करती है, उनमें व्यक्तिगत बिट्स नहीं, इसलिए आप where some_bit_mask & 12 > 0बिना पंक्ति-दर-पंक्ति स्कैन के पंक्तियों को नहीं खोज सकते ।

— ब्रैंडन

दिन के अंत में, कई-से-कई user_role_mapया user_priv_mapतालिका पर्याप्त हो जाती।

— ब्रैंडन

@MikeMcMahon, क्या आप कृपया टेबल डिज़ाइन में गहराई से गोता लगा सकते हैं और परिणाम के बारे में बात करने के लिए मुझे इसे कोड में कैसे मैप करना चाहिए?

— एलेक्स ओवचिन

@ युसर - कभी मत कहो। यकीन है कि आप बिटमास्क का उपयोग कर सकते हैं, लेकिन मैं उन्हें एक ऐसे अनुप्रयोग में उपयोग नहीं करूंगा जो एक रिलेशनल डेटाबेस का उपयोग करता है। विरासत डेटा या गति की सुपर आवश्यकता के साथ काम करते समय संभवतः कुछ किनारे मामले होते हैं।

— 21

Answer 2

आप पहले से ही संबंधित पेशेवरों और विपक्षों का नाम दे चुके हैं:

• बिट फ़ील्ड अंतरिक्ष को बचाते हैं।
• वे रिकॉर्ड में ही डेटा संग्रहीत करते हैं, इसलिए आपको उन्हें खोजने के लिए JOINs की आवश्यकता नहीं है। (लेकिन रिकॉर्ड में अलग-अलग ध्वज क्षेत्र ऐसा ही करेंगे।)
• यदि आप कच्चे SQL आउटपुट के साथ उत्पादक रूप से काम करना चाहते हैं तो वे बुरी तरह से पठनीय हैं।

निर्णय लेना है कि क्या करना है और अधिक जानकारी की आवश्यकता है:

• आपके उपयोग के मामले के लिए डिस्क स्थान कितना दुर्लभ है?
• क्या आप वास्तव में उपयोगकर्ता भूमिकाओं को इतनी बार पढ़ते हैं कि उन्हें शामिल करने का समय एक अड़चन है?
• क्या आप SQL आउटपुट को पढ़ने और उसके आधार पर निर्णय लेने जा रहे हैं - या यह एक अपठनीय डेटा बेस रिकॉर्ड इमैट्री है, इस तथ्य की तरह कि आपके सिस्टम का मशीन कोड अपठनीय है?

तो आपको क्या करना है जोखिम वाले कारकों को इकट्ठा करें और फिर उन्हें वजन दें, यह देखने के लिए कि क्या पेशेवरों ने विपक्ष को पछाड़ दिया है।

Comments

आपके उत्तर के लिए धन्यवाद, आपके विचारों से पूरी तरह सहमत हैं, लेकिन सामान्य तौर पर यह विरोधी पैटर्न है या नहीं? और क्या आप अपनी परियोजनाओं में मास्क का उपयोग करते हैं?

— एलेक्स ओवेच्किन

@ एलेक्स "बेस्ट प्रैक्टिस" जैसी कोई चीज नहीं है जो यह तय कर सके कि आपके मामले में क्या करना है। यदि आप अंतरिक्ष में बहुत कम हैं, तो बिट फ़ील्ड का उपयोग करना सबसे अच्छा अभ्यास है। यदि आप CEO को रिपोर्ट में SQL आउटपुट का उपयोग करना चाहते हैं, तो बोलने वाले नामों का उपयोग करना सबसे अच्छा अभ्यास है। लेकिन आप केवल एक ही हैं जो इन परिस्थितियों को जानते हैं, इसलिए समुदाय आपको ऐसा नुस्खा नहीं दे सकता जो हमेशा मान्य हो।

— किलन फ़ॉथ

अंतरिक्ष तर्क को "गिम्मे" के रूप में लेना। इस बात का सवाल कि क्या बिट मास्क का उपयोग करना है या इस पर पड़ता है कि क्या इससे अधिक लाभ मिलता है।

— रॉबी डे

क्या आपको डेटाबेस में जानकारी को संसाधित करने की आवश्यकता है, या क्या इसका उपयोग करने से पहले इसे हमेशा किसी एप्लिकेशन में पढ़ा जाता है।

— इयान

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

— jpmc26

Answer 3

यदि आप वास्तव में, वास्तव में , वास्तव में डिस्क स्थान के लिए स्ट्रैप्ड हैं, तो आप उपयोगकर्ता की अनुमति के लिए बिटमैप पर विचार कर सकते हैं । यदि प्रदर्शन आपकी चिंता है, तो उनके बारे में पूरी तरह से भूल जाएं, क्योंकि उन्हें अलग करना वास्तव में धीमा होगा। आप एक बिटमैप वाले फ़ील्ड को सार्थक रूप से अनुक्रमित नहीं कर सकते हैं , जिसके परिणामस्वरूप डेटाबेस टेबल स्कैन होता है, जो [लगभग] हमेशा एक प्रदर्शन हत्यारा है।

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

कोई भी गंभीर डीबीएमएस उस "अतिरिक्त जुड़ाव" को बिना पलक झपकाए भी संभाल सकता है।

Comments

+1: अच्छे संबंधपरक डेटाबेस उन लोगों द्वारा विकसित किए जाते हैं जो वास्तव में, वास्तव में, वास्तव में अच्छे हैं जो वे करते हैं। बिट फ़ील्ड का उपयोग करके आपको प्राप्त होने वाले प्रदर्शन के अंतिम बिट को लिखने की आवश्यकता के स्तर पर किसी को भी सवाल पूछने की आवश्यकता नहीं होगी। डेटा मॉडल करें, फिर उन भागों को ढूंढें जो प्रदर्शन नहीं करते हैं।

— ब्लफ

ज्वाइन होने से एप्लिकेशन कोड और अधिक जटिल हो जाएगा, इसलिए भूमिकाएं संसाधित होने पर बहुत कुछ नीचे आ जाता है।

— इयान

@ मैं शामिल होने के लिए यह जानने की जरूरत से ज्यादा जटिल नहीं है कि बिटकॉइन अनुमतियों को कैसे समझा जाए।

— ब्रैड

@ ब्रैड, एक एनम के बारे में सोचें जो सी # में ध्वज का एक सेट है, इसके मूल्य को "जैसा है" डेटाबेस में संग्रहीत किया गया है, सी # कोल्ड को कोई सरल नहीं मिल सकता है। यदि एक जुड़ाव का उपयोग किया जाता है, तो C # कोड को "1 से कई" संबंधों का सामना करना पड़ता है।

— इयान

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

— ब्लर

Answer 4

जब भंडारण महंगा था, तो बिट मास्क के साथ वरदान यह था कि उन्होंने अंतरिक्ष को बचा लिया। बड़े डेटा के दिनों में, यह एक बार यह मुद्दा नहीं था।

उदाहरण का हवाला देते हुए - एक बिट मास्क के रूप में संग्रहीत भूमिकाओं को देखने के लिए डेटाबेस डिज़ाइन बिंदु से कोड गंध का कुछ होगा क्योंकि यह पहले सामान्य रूप का उल्लंघन होगा । इस अर्थ में, वे एक विरोधी पैटर्न हैं।

यह सब कहा जा रहा है, यह एक या दूसरे होना जरूरी नहीं है। आप डेटा को एक बिट मास्क के रूप में संग्रहीत कर सकते हैं और फिर एक दृश्य हो सकता है जो मक्खी पर उपयोगकर्ता की भूमिका को खींच सकता है। आपको तब भी एक नज़र में जाँच का लाभ होगा जो उपयोगकर्ताओं की समान भूमिकाएँ थीं।

Answer 5

बिटमास्क का उपयोग करने का एकमात्र लाभ यह है कि यदि बिट फ़ील्ड का अर्थ स्थिर नहीं है। यदि आप प्रत्येक क्षेत्र में रिकॉर्ड पर हैं, तो समय से पहले पता करने पर संबंधपरक तालिकाएं अच्छी तरह से काम करती हैं: आपको CREATE TABLEडीडीएल स्टेटमेंट में उन सभी क्षेत्रों की पहचान करनी होगी ।

यदि प्रत्येक बिट फ़ील्ड का अर्थ रनटाइम पर कॉन्फ़िगर करने योग्य है, या अन्यथा समय से पहले ज्ञात नहीं है, तो यह बूलियन को बिट फ़ील्ड के रूप में संग्रहीत करने के लिए समझ में आ सकता है । : फिर भी, यह संभव मनमाना क्षेत्रों के साथ एक मेज को परिभाषित करने के लिए है field_1, field_2हालांकि अभी भी आदर्श नहीं, आदि यह आपको एक क्लीनर रिलेशनल डिजाइन देता है। क्या यह थोड़ा क्षेत्र के लिए बेहतर है, मोटे तौर पर राय का विषय है, क्योंकि न तो समाधान आदर्श है।

यदि आप जानते हैं कि विकास के दौरान बिट्स क्या दर्शाते हैं, तो प्रत्येक बिट के लिए फ़ील्ड बनाएं और उन्हें सार्थक नाम दें ।

बस आंतरिक मंच प्रभाव से सावधान रहें । यदि आप अंत में मनमाने ढंग से लेकिन अच्छी तरह से टाइप किए गए फ़ील्ड को परिभाषित करते हैं, जो कि एक बात है, लेकिन यदि आप इससे बहुत अधिक दूर जाते हैं, तो आप एक रिलेशनल डेटाबेस को पुनः प्राप्त कर रहे होंगे ... एक रिलेशनल डेटाबेस के अंदर।

Answer 6

मैं बिटकॉइन को लेकर महत्वाकांक्षी हूं। मुझे लगता है कि उनके अधिकांश गुप्तचर बाइनरी और हेक्साडेसिमल को नहीं समझते हैं। स्पष्टता के लिए, अच्छे mnemonics का उपयोग करें।

ऊपर उल्लेख नहीं किया गया लाभ एक नए कॉलम के संभावित समय लेने वाले जोड़ के बिना बिट मास्क में नए अर्थ को जोड़ने की क्षमता है। हमारे डीबी डिज़ाइनर्स (जो मुझसे पहले थे) ने उन्हें एक टेबल में रखा है जो अब 5 मिलियन नए रिकॉर्ड रोज़ाना प्राप्त करता है। नए व्यवहार का प्रतिनिधित्व करने के लिए एक नए कॉलम को जोड़ने में एक लंबा समय लगेगा, जबकि एक नए बिट को परिभाषित करना (हमने 33 में से 64 का उपभोग किया है) के लिए कोई तालिका पुनर्निर्माण की आवश्यकता नहीं है।

नहीं, बिट मास्क को अनुक्रमित नहीं किया जा सकता है, लेकिन 33 इंडेक्स का निर्माण हास्यास्पद होगा और क्रॉल में सम्मिलन को धीमा कर देगा। तालिका खोजें दिनांक और रिकॉर्ड "स्वामियों" अनुक्रमित का उपयोग करती हैं, इसलिए यदि संभव हो तो इस बिट मास्क पर अनुक्रमित किया जाएगा।

Comments

यह एक दिलचस्प मामला है। मुझे लगता है कि आप टेबल पर "स्पेयर" कॉलम को परिभाषित करके और फिर आवश्यकतानुसार इनका उपयोग करके, एक कोषेर और स्पष्ट फैशन में समान हासिल कर सकते थे। फिर आप इन स्तंभों को कम से कम अनुक्रमित कर सकते हैं, क्या आपको ऐसा करने के लिए चुनना चाहिए।

— स्टीव

Answer 7

यदि लक्ष्य कुछ डिस्क स्थान को बचाने के लिए है, तो मुझे लगता है कि यह एक बुरा विचार है:

• आज जीबी की लागत को देखो,
• इसकी तुलना उन लोगों के समय की लागत से करें, जो रिपोर्ट और प्रश्न लिखते हैं और यह पता लगाना है कि क्षेत्र में क्या है, और एक विशिष्ट बिट को कैसे संबोधित किया जाए, लागत / लाभ की तुलना गलत पक्ष पर समाप्त हो सकती है।
• यदि आप SQL डेटाबेस के साथ काम कर रहे हैं, तो कई क्वेरियों में आवश्यक अतिरिक्त बिट एक्सेस ऑपरेशन भी आवश्यकता से अधिक कंप्यूटिंग समय का उपभोग कर सकते हैं

हालांकि कुछ मामले हैं, जो बिट फ़ील्ड्स के उपयोग को जसिटफिय कर सकते हैं:

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