टिनीट बनाम बिट?

Question

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

केवल अंतर जो मुझे पता है ये हैं:

• bit: भंडारण का आकार 1 बिट है, संभावित मान 0 या 1 हैं
• tinyint: भंडारण आकार 1 बाइट है, संभावित मान 0-255 हैं

जब आप बूलियन मूल्यों का प्रतिनिधित्व करने की आवश्यकता होती है तो कौन सा डेटा प्रकार बेहतर है? tinyintअतिरिक्त ओवरहेड के लायक है "बस मामले में" आपको मूल्यों> 1 की आवश्यकता है?

Comments

"बस के मामले में" एक सुंदर तरल पदार्थ डेटाबेस डिजाइन की तरह लगता है। क्यों नहीं सब कुछ NVARCHAR (MAX) के रूप में संग्रहीत करें और अपने सभी ठिकानों को कवर करें?

— स्टुअर्ट आइन्सवर्थ

TinyInt मेरी प्राथमिकता है। फिर, जब कुल मिलाकर क्षेत्र के खिलाफ मायने रखता है, तो आपको इसे डालने की जरूरत नहीं है। इसके अलावा, कुछ फ्रंट-एंड भाषाएं दूसरों की तुलना में बिट को अलग तरह से व्याख्या करती हैं, और टाइनीइंट का उपयोग किसी भी फ्रंट-एंड भाषा के लिए सत्यापन जांच को सार्वभौमिक बनाता है।

— ग्रेगरी हार्ट

मैं बस phpMyAdmin में बिट के साथ एक विषमता का सामना करना पड़ा। जब मैं यह बताता हूं कि फ़ील्ड को NULL होने दें और कोई डिफ़ॉल्ट मान सेट नहीं है, तो यह NULL के बजाय <em> NULL </ em> में डिफॉल्ट करता है। टिंटिन बीटीटी के लिए +1

— वोरस अमेडिया

जब फॉर्म का आयात सीएसवी फ़ाइल 1 टिंटिंट (1) के मामले में काम करता है, लेकिन बिट (1) के मामले में आपको इसे b'1 में बदलना होगा

— रजत

Answer 1

जब आप अपनी तालिका में थोड़ा कॉलम जोड़ते हैं तो यह केवल एक बिट नहीं, बल्कि प्रत्येक रिकॉर्ड में एक पूरी बाइट पर कब्जा कर लेगा। जब आप दूसरा बिट कॉलम जोड़ते हैं तो इसे उसी बाइट में संग्रहीत किया जाएगा। नौवें बिट कॉलम को भंडारण के दूसरे बाइट की आवश्यकता होगी। 1 बिट कॉलम के साथ तालिकाओं को कोई भंडारण लाभ नहीं मिलेगा।

टिनीट और बिट दोनों को काम करने के लिए बनाया जा सकता है, मैंने दोनों का सफलतापूर्वक उपयोग किया है और इसकी कोई मजबूत प्राथमिकता नहीं है।

Comments

यह एक बहुत ही उपयोगी टिप्पणी है और आपकी प्रतिष्ठा काफी अच्छी है लेकिन क्या आपके पास इसका समर्थन करने के लिए कोई संदर्भ है? क्या यह एक कार्यान्वयन विवरण है या क्या सभी इंजन इसे उसी तरह से संभालते हैं?

— जॉन जेड

@Jonz MySQL के लिए यहाँ देखें ।

— shmosel

@Shosel के संदर्भ से यह बिल्कुल स्पष्ट है कि 1 बिट (1) कॉलम 1 बाइट लेता है, लेकिन यह इतना स्पष्ट नहीं है कि दो, तीन, चार ... आठ बिट (1) कॉलम एक ही बाइट लेते हैं। मैंने वह सफलता के बिना ऑनलाइन खोज की है। क्या आप भी इसका संदर्भ दे सकते हैं? मुझे यह जानने में दिलचस्पी है कि क्या, अगर मुझे ऐसा लगता है कि चार बुलियन कॉलम हैं जो मुझे अपनी मेज के लिए चाहिए, तो स्टोरेज स्पेस को बचाने के लिए टिनीलिंट (1) के बजाय बिट (1) कॉलम का उपयोग करने के लायक हो सकता है। धन्यवाद।

— डेन्सी

@assensi अच्छी बात है। आप हमेशा खेतों के BIT(n)स्थान पर एकल का उपयोग कर सकते हैं n। या आप एक नियमित रूप से उपयोग कर सकते हैं INTऔर प्रत्येक बूलियन को थोड़ा सा स्टोर कर सकते हैं । लेकिन अगर आप अलग-अलग क्षेत्रों में जा रहे हैं, तो मुझे लगता TINYINTहै कि आमतौर पर MySQL में पसंद किया BITजाता है।

— shmosel

Answer 2

बिट ... जब तक आप "सच्चे / झूठे / फ़ाइल नहीं मिले" कबीले के नहीं हैं

मामले में आपको संदर्भ नहीं मिला ...

और Linq2SQL के मामले में, बिट सही / गलत के साथ काम करता है जो इसके लिए प्रोग्राम करना आसान बनाता है। दोनों के फायदे हैं।

और विचार करने के लिए प्रोग्रामिंग रखरखाव भी है। यदि आप (या एक जूनियर इंटर्न प्रोग्रामर) 2, 3, 25, 41, 167, 200 आदि का उपयोग करता है तो क्या होगा? वह दस्तावेज कहां है? बिट्स स्व-दस्तावेजीकरण और बहुत सार्वभौमिक हैं।

Comments

बिट्स अशक्त हैं इसलिए आप अभी भी टी / एफ / एफएनएफ कर सकते हैं।

— ऑस्टिन सलूनन

और NULL FNF की बराबरी करना कितना बुरा है? :) सच में thedailywtf के योग्य!

— जॉन रूडी

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

— कोडमोंकी

Answer 3

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

संदर्भ:

• SQL 2000
• SQL 2005
• SQL 2008

Answer 4

MySql उपयोगकर्ताओं के लिए - आपको MySQL में BIT कॉलम का उपयोग क्यों नहीं करना चाहिए

Comments

हम्म, "क्यों आप MySQL का उपयोग नहीं करना चाहिए" प्रविष्टि की तरह लग रहा है ... :-)

— ब्रायन नोब्लुक

नियत: 5.0.23, 5.1.12 चैंज में नोट किया गया। किसी तालिका में BIT स्तंभ जुड़ सकते हैं जो तालिका का उपयोग करने में विफल हो सकते हैं।

— एंट्टी रयोटोला

Answer 5

पिछली StackOverflow पोस्ट: MySQL में BIT और TINYINT में क्या अंतर है?

एक नया "BOOL" कॉलम जोड़ते समय, MySQL वास्तव में TINYINT का उपयोग करता है।

मैं बस BOOL (उर्फ टिनिनेट ) के साथ रहना चाहता हूं और जीवन के साथ आगे बढ़ना चाहता हूं ।

Answer 6

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

Answer 7

मैं बिट का उपयोग करता हूं क्योंकि यह मुझे एक चेक बाधा का उपयोग करने से बचाता है, और क्योंकि मेरा ओआरएम स्वचालित रूप से बिट को एक अशक्त बूलियन (सी #) में बदल देगा, जिसे मैं एक बार कोडिंग के लिए बहुत सराहना करता हूं।

Answer 8

झूठे के लिए शून्य स्थान

आपकी पसंद जो भी हो, आप NULLइसके बजाय सेट कर सकते हैं 0और यह कोई अतिरिक्त स्थान नहीं लेगा (क्योंकि डेटाबेस में लगभग हमेशा NULLहर पंक्ति के हर क्षेत्र के लिए एक झंडा होता है , बस वहां बैठे; अधिक जानकारी यहाँ )। यदि आप यह भी सुनिश्चित करते हैं कि डिफ़ॉल्ट / सबसे अधिक संभावना है false, तो आप और भी अधिक स्थान बचा लेंगे!

ट्रू के लिए कुछ स्पेस

प्रतिनिधित्व करने के trueलिए फ़ील्ड प्रकार द्वारा परिभाषित स्थान की आवश्यकता होती है; का उपयोग करते हुए BITकेवल अंतरिक्ष की बचत होगी अगर एक मेज कई ऐसे स्तंभ हैं, क्योंकि यह 8 क्षेत्रों प्रति एक बाइट का उपयोग करता है (बनाम TINYINTजो क्षेत्र प्रति एक बाइट का उपयोग करता है)।

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

किसी भी मामले में, TEXTबूलियन या उनमें से सेट को स्टोर करने के लिए खेतों का उपयोग करने के प्रलोभन से बचें । पाठ के माध्यम से खोज करना सर्वर के लिए बहुत अधिक काम है, और "चालू, बंद, बंद" जैसी मनमाने ढंग से नामकरण योजनाएं अंतर-अस्थिरता को चोट पहुंचा सकती हैं।

Answer 9

मैंने बस बिट (SQL सर्वर 2k5) पर समूहीकरण करने की कोशिश की और यह मेरे लिए ठीक काम किया। मुझे एप्लिकेशन के लिए सही डेटा प्रकार का उपयोग करना पसंद है। यदि यह एक सही / गलत क्षेत्र है, तो बिट मैं क्या उपयोग करता है ...

Answer 10

ये सभी सैद्धांतिक चर्चाएं बहुत अच्छी हैं, लेकिन वास्तव में, कम से कम यदि आप MySQL और वास्तव में SQLServer के लिए उपयोग कर रहे हैं, तो आपके बूलियंस के लिए गैर-द्विआधारी डेटा के साथ चिपकना सबसे अच्छा है क्योंकि यह आसान है जब आप के साथ काम करना आसान हो। 'डेटा का उत्पादन, क्वेरी और इतने पर। यह विशेष रूप से महत्वपूर्ण है यदि आप MySQL और SQLServer (यानी आप दोनों के बीच डेटा सिंक करते हैं) के बीच अंतर को प्राप्त करने की कोशिश कर रहे हैं, क्योंकि दोनों में BIT डेटाटाइप का हैंडलिंग अलग है। यदि आप एक संख्यात्मक डेटाटाइप के साथ चिपके रहते हैं तो आपको बहुत कम परेशानी होगी। मैं MySQL के लिए BOOL या BOOLEAN से चिपके रहने की सलाह दूंगा जो TINYINT (1) के रूप में संग्रहीत हो जाता है। यहां तक ​​कि जिस तरह से MySQL वर्कबेंच और MySQL एडमिनिस्ट्रेटर BIT डेटाटाइप दिखाते हैं वह अच्छा नहीं है (यह बाइनरी डेटा के लिए थोड़ा प्रतीक है)।

Answer 11

मुझे नहीं लगता कि मैंने इसे ऊपर उल्लिखित देखा था, लेकिन बीआईटी कॉलम (जैसे MIN, MAX, और विशेष रूप से SUM) को एकत्रित नहीं करने का मुद्दा है। मैंने सिर्फ 2008 का उपयोग करके परीक्षण किया और मुद्दा अभी भी है। यही सबसे बड़ा कारण है कि मैं हाल ही में टिनीट का उपयोग करता हूं - दूसरे मैं यह पसंद करता हूं कि कैसे टिंटिंट स्केल होता है - यह हमेशा एक दर्द होता है जब आपके "दो-मूल्य" बिट फ्लैग को अचानक अधिक संभव मानों की आवश्यकता होती है।

Comments

आप उन्हें किसी अन्य डेटाटाइप में कास्टिंग करके एकत्र कर सकते हैं - आपको सही / गलत की राशि की आवश्यकता क्यों होगी?

— मार्टिन स्मिथ

हम अक्सर एक क्षेत्र पर समूह बनाते हैं और परिणाम के आधार पर प्रत्येक समूह के लिए दूसरे क्षेत्र के कितने सही होते हैं, योग का विकल्प पूरे परिणाम को कोड करने और इसे लूप करने के लिए होगा, कभी-कभी क्लाइंट को 1000x अधिक डेटा वापस करने के परिणामस्वरूप। । लेकिन कास्टिंग इसे खत्म कर देती है, इसलिए यह कोई समस्या नहीं है।

— डेविड मर्टेनसन

Answer 12

हम अपने सभी तालिकाओं को एक इंट "वेक्टर" फ़ील्ड के साथ बनाते हैं। हम उस फ़ील्ड को 32 बिट्स के संग्रह के रूप में उपयोग करते हैं जिसे हम किसी भी उद्देश्य के लिए असाइन कर सकते हैं। (राज्यों के एक समूह के लिए बिट्स के समूह का उपयोग करके संभावित रूप से)। यदि हम भूल जाते हैं तो हमें ध्वज क्षेत्रों में शामिल करने से बचाते हैं।

Comments

इसे ऑबफ्यूजन भी कहा जाता है। या, बिछाने वाले व्यक्ति को, "रखरखाव दुःस्वप्न।"

— रॉबर्ट सी। बर्थ

आप बस अपनी सभी सारणियों को एक ही पाठ स्तंभ बना सकते हैं और वहाँ सब कुछ अल्पविराम में डाल सकते हैं। तब आपको अपना डेटा मॉडल बदलना नहीं पड़ेगा।

— टॉम एच

हमारे पास कुछ अनोखा वातावरण है। हमारे पास बहुत बड़े डेटासेट और 4 9 के अपटाइम हैं, इसलिए तालिकाओं में फेरबदल करना निषेधात्मक है (दोहराएं कि जहां प्रतिकृति शामिल है)। हम सभी बिट्स को एक केंद्रीकृत स्थान पर ट्रैक करते हैं, जो रखरखाव के मुद्दे से बचने में मदद करता है।

— जो

Answer 13

@ केविन: मेरा मानना ​​है कि आप group byबिट फ़ील्ड (SQL Server 2005) पर उपयोग कर सकते हैं :

declare @t table (
    descr varchar(10),
    myBit1 bit, 
    myBit2 bit
)
insert into @t values ('test1', 0, 1)
insert into @t values ('test2', 1, 0)
insert into @t values ('test3', 1, 1)
insert into @t values ('test4', 0, 0)

select myBit1, count(myBit1) from @t group by myBit1
select myBit2, count(myBit1) from @t group by myBit2

परिणाम:

myBit1 
------ -----------
0      2
1      2

myBit2 
------ -----------
0      2
1      2

Answer 14

TinyInt मेरी प्राथमिकता है। फिर, जब कुल मिलाकर क्षेत्र के खिलाफ मायने रखता है, तो आपको इसे डालने की जरूरत नहीं है। इसके अलावा, कुछ फ्रंट-एंड भाषाएं दूसरों की तुलना में बिट की अलग-अलग व्याख्या करती हैं, और टाइनीइंट का उपयोग किसी भी फ्रंट-एंड भाषा के लिए सत्यापन जांच को सार्वभौमिक बनाता है।

Answer 15

यदि आप MySQL का उपयोग कर रहे हैं, तो यह BIT डेटा प्रकार - http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/ का उपयोग करने के लिए अनुशंसित नहीं है ।

Answer 16

मुझे 'T' या 'F' के साथ char (1) का उपयोग करना पसंद है। हाँ, अन्य मूल्यों के साथ दुर्व्यवहार किया जा सकता है लेकिन कम से कम रिपोर्टों या अन्य स्थानों पर यह देखना आसान है जहां बिट या बाइनरी मान के साथ काम करना कठिन है।

Comments

आप केवल "T" और "F" की अनुमति देने के लिए कॉलम में आसानी से एक बाधा डाल सकते हैं (और चाहिए)। कहा जा रहा है, रिपोर्टिंग परत डेटाबेस से पूरी तरह से अलग होना चाहिए। किसी कॉलम को कैसे प्रदर्शित किया जाएगा, इसके उद्देश्यों के लिए आपको अपने डेटाबेस स्कीमा में बदलाव नहीं करना चाहिए।

— टॉम एच

मैं डैरिल से सहमत हूं। सामान्य RDBMS सिस्टम (MySQL यहाँ अकेला नहीं है) में बूलियन प्रकारों के लिए समर्थन की कमी को देखते हुए टी / एफ (वास्तव में मुझे वाई / एन पसंद है) बहुत अधिक पठनीय है। जबकि मैं टॉम एच की टिप्पणियों के साथ सिद्धांत रूप में सहमत हूं, मुझे लगता है कि पठनीयता उनके लिए श्रेय देने की तुलना में बहुत अधिक महत्वपूर्ण है। डेटाबेस डेवलपर्स किसी और के कोड को बदलते समय सामने के छोर को नहीं देखते हैं! इसके अलावा, यह हमेशा स्पष्ट नहीं होता है कि किस तरह से एक डेवलपर 1 और 0 को गोल करता है। यदि हम सभी इसे 'उचित' पुराने ढंग से कर रहे थे, तो हम -1सच्चे 0का प्रतिनिधित्व करने के लिए , और झूठ का प्रतिनिधित्व करने के लिए उपयोग करेंगे ।

— कार्टबेफ्रॉर्से

अपनी पिछली टिप्पणी में, मुझे यह जोड़ना चाहिए कि ऐसा लगता है जैसे MySQL CHECK बाधाओं का समर्थन नहीं करता है, जो कि T / F विकल्प को जटिल करेगा, क्योंकि आप वर्णमाला के किसी अन्य वर्ण द्वारा आबादी वाले कॉलम को रोक नहीं सकते हैं। अच्छा नहीं है।

— कार्टेफोरहोर्स