क्या एक अच्छा कारण है कि मैं VARCHAR (255) को इतनी बार इस्तेमाल किया गया (जैसा कि एक और लंबाई के विपरीत है)?

Question

कई पाठ्यक्रमों, पुस्तकों और नौकरियों में, मैंने पाठ फ़ील्ड को "लघु" पाठ के लिए डिफ़ॉल्ट के रूप में VARCHAR (255) के रूप में परिभाषित देखा है। क्या कोई अच्छा कारण है कि 255 की लंबाई को इतनी बार चुना जाता है, एक अच्छा दौर संख्या होने के अलावा ? क्या यह अतीत में कुछ समय से एक होल्डआउट है जब कोई अच्छा कारण था (आज लागू होता है या नहीं)?

मुझे एहसास है कि निश्चित रूप से, एक तंग सीमा अधिक आदर्श होगी, यदि आप किसी तरह से स्ट्रिंग की अधिकतम लंबाई जानते हैं। लेकिन अगर आप VARCHAR (255) का उपयोग कर रहे हैं जो संभवतः इंगित करता है कि आप अधिकतम लंबाई नहीं जानते हैं, केवल यह कि यह "संक्षिप्त" स्ट्रिंग है।

---

नोट: मैं इस सवाल (पाया varchar (255) वी tinyblob वी tinytext ) है, जो कहता है कि VARCHAR ( n ) की आवश्यकता है n के लिए भंडारण की +1 बाइट्स n <= 255, एन के लिए भंडारण की 2 बाइट्स n > 255। क्या यह एकमात्र कारण है? यह एक प्रकार का मनमाना है, क्योंकि आप VARCHAR (256) की तुलना में केवल दो बाइट्स बचा रहे होंगे, और आप इसे VARCHAR (253) घोषित करके आसानी से एक और दो बाइट्स बचा सकते हैं।

Answer 1

ऐतिहासिक रूप से, 255 वर्ण अक्सर VARCHARकुछ DBMSes में अधिकतम लंबाई के होते हैं, और यदि आप UTF-8 का उपयोग करना चाहते हैं और अनुक्रमणिका की लंबाई सीमाओं के कारण स्तंभित करना चाहते हैं, तो यह कभी-कभी प्रभावी रूप से अधिकतम होता है।

Comments

@CharlesBretana: यदि आप उद्धृत किए गए शेष वाक्य को पढ़ते हैं, तो आप सटीक विवरण प्राप्त करेंगे जो आप अनुरोध कर रहे हैं।

— अराजकता

@CharlesBretana: "नकली UTF-8" से मेरा मतलब है MySQL की "utf8" एन्कोडिंग, जिसका उल्लेख मैंने भंडार के रूप में किया है (और यह सीमित है) प्रति वर्ण 3 बाइट्स। यह UTF-8 का बहुत अच्छा संस्करण नहीं है; यदि आप MySQL में सभ्य UTF-8 चाहते हैं, तो आपको इसके "utf8mb4" एन्कोडिंग का उपयोग करना होगा। लेकिन लोगों को यह पता नहीं है कि "utf8" के साथ जाने की अधिक संभावना है, और किसी भी अन्य एन्कोडिंग की तुलना में UTF-8 के लिए अधिक संभावना है, इसलिए, presto, वे एक VARARAR में 255 वर्णों की अधिकतम इंडेक्सेबल लंबाई के साथ हवा करते हैं। आपकी अचरज के बावजूद।

— अराजकता

@CharlesBretana: मैंने अब इसे तीन बार समझाया है और एक भी चीज़ नहीं बदली है। MySQL की सूचकांक लंबाई सीमा अभी भी 767 बाइट्स है, 3-बाइट UTF-8 वर्ण को एनकोड करने के लिए आवश्यक बाइट्स की संख्या अभी भी 3 है, और फर्श (767/3) अभी भी 255 है। भिखारियों के विश्वास के बारे में भ्रमित होने के लिए कुछ खोजने के लिए आपका दृढ़ संकल्प ।

— अराजकता

@CharlesBretana (इस पूरी पार्टी के लिए देर से आने के लिए क्षमा करें) मैं कोई DB विशेषज्ञ नहीं हूं, लेकिन मुझे लगता है कि अराजकता क्या कह रही है: हाँ 'Fake UTF-8' कॉलम 255 वर्णों से अधिक लंबा हो सकता है, लेकिन सूचकांक होगा केवल varchar के पहले 255 अक्षरों पर काम करते हैं, अगर आप इसे पूरी तरह से अनुक्रमित करना चाहते हैं, तो यह प्रभावी रूप से एक कॉलम की अधिकतम क्षमता बनाता है। अब केवल वही है जो मैंने उनके स्पष्टीकरण के बारे में समझा, मैं गलत हो सकता हूं, मैं एसक्यूएल इंडेक्स में बिल्कुल भी विशेषज्ञ नहीं हूं।

— फ्रांसिस लॉर्ड

@CharlesBretana यदि आप कैओस के उत्तर को ठीक से देखते हैं, तो आप इसे 2 भागों में अलग-अलग देखेंगे: 1. वर्चर के पीछे ऐतिहासिक कारण (255) इतना सामान्य है (यह कुछ पुराने DBMS पर अधिकतम हुआ करता था), 2। आज भी, यह अभी भी कुछ के लिए एक सीमा है क्योंकि पहले चर्चा की गई सूचकांक सीमाओं के कारण, भाग 1 और 2 लिंक नहीं हैं। भाग 1 प्रश्न का वास्तविक उत्तर है, भाग 2 एक साइड नोट है जो अभी भी प्रश्न के लिए प्रासंगिक है क्योंकि यह बताता है कि क्यों आज भी यह एक सीमा हो सकती है। (संपर्क ->)

— फ्रांसिस लॉर्ड

Answer 2

255 का उपयोग किया जाता है क्योंकि यह वर्णों की सबसे बड़ी संख्या है जिन्हें 8-बिट संख्या के साथ गिना जा सकता है। यह 255 से ऊपर के वर्णों को गिनने के लिए एक और पूरे बाइट की आवश्यकता के बिना, 8-बिट गिनती के उपयोग को अधिकतम करता है।

जब इस तरह से उपयोग किया जाता है, तो VarChar आपके पाठ को संग्रहीत करने के लिए केवल बाइट्स + 1 की संख्या का उपयोग करता है, इसलिए आप इसे 255 तक सेट कर सकते हैं, जब तक कि आप फ़ील्ड में वर्णों की संख्या पर एक कठिन सीमा (जैसे 50) नहीं चाहते।

Comments

मुझे वह वाक्यांश पसंद है: "पूरी तरह से एक और बाइट की आवश्यकता होती है"। =)

— मुसिएनेसिस

क्या यह DBs के लिए सही है जहाँ varchars UTF-8 हैं?

— एंटक

@antak: MySQL में, InnoDB का उपयोग करके, कोई भी मुख्य कॉलम 767 बाइट्स से बड़ा नहीं हो सकता है। यदि एक VARCHAR स्तंभ UTF8 है (जिसका अर्थ है कि प्रत्येक चार बाइट्स तक ले जा सकता है), स्तंभ की अधिकतम अनुमत लंबाई मंजिल (767/3) = 255 है। मैं मान रहा हूं कि "767" को ठीक उसी कारण से चुना गया था।

— ब्लूराजा - डैनी पफ्लुगुफ़ेक्ट '

यदि चारसेट हैutf8 , varchar(85)तो वह सीमा है , जिस पर क्रॉसिंग की लंबाई एक से दो बाइट्स तक होती है। अगर यह है utf8mb4, यह है varchar(63)। ये महत्वपूर्ण हैं क्योंकि वे अधिकतम हैं जिनके लिए एक VARCHAR की लंबाई ऑनलाइन अलर्ट के उपयोग के माध्यम से बढ़ाई जा सकती है । नतीजतन, मैंने उन संख्याओं को एक varchar(2) charset utf8स्तंभ के साथ एक तालिका बनाकर निकाला और यह देखते हुए कि मैं इसे दिए गए विस्तार में कितना सक्षम था ALGORITHM=INPLACE।

— एंटैक ११'१

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

— टीएमएन

Answer 3

संभवतः क्योंकि SQL सर्वर और Sybase (नाम दो से मैं परिचित हूं) एक VARCHARकॉलम में वर्णों की संख्या में अधिकतम 255 वर्ण होते थे । SQL सर्वर के लिए, यह 1996/1997 में संस्करण 7 में बदल गया ... या फिर ... लेकिन पुरानी आदतें कभी-कभी कठिन हो जाती हैं।

Comments

विशिष्ट DB और संस्करणों का हवाला देते हुए +1। और "पुरानी आदतें मुश्किल से मरती हैं" शायद सभी का सबसे कठिन जवाब है।

— एंड्रयू एम

Answer 4

मैं शाब्दिक प्रश्न का उत्तर देने जा रहा हूं: नहीं , कोई अच्छा कारण नहीं है जिसे आप VARCHAR (255) को इतनी बार उपयोग करते हुए देखते हैं (वास्तव में कारण हैं , जैसा कि अन्य उत्तरों में चर्चा की गई है, बस अच्छे नहीं हैं)। आपको उन परियोजनाओं के कई उदाहरण नहीं मिलेंगे जो भयावह रूप से विफल रहे हैं क्योंकि आर्किटेक्ट ने VARCHAR (255) के बजाय VARCHAR (300) को चुना था। भले ही आप VARCHAR के बजाय CHAR के बारे में बात कर रहे हों, यह निकट-कुल महत्व का मुद्दा होगा।

Comments

255 में से 1 बाइट 0.4% है। कभी-कभी आप पिछले आधे प्रतिशत या उसके बारे में परवाह करते हैं। कभी-कभी आप नहीं। यदि आप होस्टिंग और संपूर्ण लागत दसियों डॉलर में चलाते हैं, तो आप शायद परवाह नहीं करते हैं। यदि वे लाखों में चलते हैं, तो वे शायद करते हैं।

— एडवर्ड ब्रे

@EdwardBrey: अगर मूर का कानून अभी भी सही है, तो मेरा जवाब यहां से 16 गुना अधिक वैध है, जब मैंने इसे लिखा था।

— मुसिएनेसिस

जब तक हमने 16 गुना अधिक तरीके नहीं खोज लिए हैं, कंप्यूटर हमारी मदद कर सकते हैं। गति अभी भी एक विशेषता है।

— एडवर्ड ब्रे

Answer 5

जब आप कहते हैं कि 2^8आप प्राप्त करते हैं 256, लेकिन कंप्यूटर शब्दों में संख्याएं संख्या से शुरू होती हैं 0। तो, फिर आपको मिल गया 255, आप इसे आईपी या आईपी में ही इंटरनेट मास्क में देख सकते हैं।

255 8 बिट पूर्णांक का अधिकतम मूल्य है: 11111111 = 255

क्या उससे मदद हुई?

Comments

पूर्णांक के साथ, आप 0 से शुरू करते हैं और आप 255 पर समाप्त होते हैं। लेकिन स्ट्रिंग में स्थानों के साथ, आप 1 स्थान से शुरू करते हैं, इसलिए इसका 256 वें स्थान पर समाप्त होने का कोई मतलब नहीं है, क्योंकि आपने 1 के बजाय 1 पर प्रारंभ किया था 0? मैं string_length () परिणामों के कारण पूरी तरह से अभी तक varchar (256) के साथ सहमत नहीं हूं, लेकिन मैं वास्तव में निश्चित नहीं हूं।

— होल्डऑफहंगर

@HoldOffHunger स्ट्रिंग्स में एक डेटाबेस में शून्य वर्णों की लंबाई हो सकती है, इसलिए लंबाई की अनुमेय सीमा जब आठ बिट्स में संग्रहीत की जाती है, तो 0 से 255 के बीच होती है। यदि आप यह कहना चाहते हैं कि स्ट्रिंग्स में कम से कम एक वर्ण होना चाहिए, तो आप आठ-बिट लंबाई के साथ 256-वर्ण स्ट्रिंग्स का समर्थन कर सकता है।

— फोगोग १४'१

Answer 6

नोट: मैं इस सवाल (पाया varchar (255) वी tinyblob वी tinytext ) है, जो कहता है कि VARCHAR ( n ) की आवश्यकता है n के लिए भंडारण की +1 बाइट्स n <= 255, एन के लिए भंडारण की 2 बाइट्स n > 255। क्या यह एकमात्र कारण है? यह एक प्रकार का मनमाना है, क्योंकि आप VARCHAR (256) की तुलना में केवल दो बाइट्स बचा रहे होंगे, और आप इसे VARCHAR (253) घोषित करके आसानी से एक और दो बाइट्स बचा सकते हैं।

नहीं, आप 253 को घोषित करके दो बाइट्स नहीं बचाते हैं। चरचर का कार्यान्वयन सबसे लंबा काउंटर और एक चर लंबाई, गैर-अलग सरणी है। इसका मतलब है कि यदि आप "हैलो" को एक वर्चर (255) में संग्रहीत करते हैं तो आप 6 बाइट्स पर कब्जा कर लेंगे: लंबाई के लिए एक बाइट (संख्या 5) और पांच अक्षरों के लिए 5 बाइट्स।

Comments

यह कथन सभी डेटाबेस के लिए सही नहीं है। कई डेटाबेस तालिकाओं में दिए गए आकार के varchar फ़ील्ड का उपयोग करते हैं ताकि उन्हें उस पंक्ति के चारों ओर ले जाने की आवश्यकता न पड़े जब उस पंक्ति के लिए फ़ील्ड बदल दी जाए।

— सिंगलएनजेशन इलेक्शन 21

हाँ आप सही है। यह कार्यान्वयन पर निर्भर है। आपको वेंडर मैनुअल को यह देखने के लिए देखना होगा कि मामला क्या है

— स्टेफानो बोरीनी

यह अनुमेय हो सकता है, लेकिन VARCHARउस तरह से लागू करना इसके बजाय उपयोग करने के पूरे बिंदु को हरा देता VARCHARहै CHAR।

— dan04

Answer 7

एक अहस्ताक्षरित 1 बाइट संख्या में सीमा [0-255] शामिल हो सकती है। इसलिए जब आप 255 देखते हैं, तो यह अधिकतर होता है क्योंकि प्रोग्रामर बेस में सोचते हैं 10(मज़ाक करें?) :)

दरअसल, कुछ समय के लिए, 255 सबसे बड़ा आकार था जो आप MySQL में एक वर्चकार दे सकते हैं, और अनुक्रमण और अन्य मुद्दों के साथ पाठ पर वार्च का उपयोग करने के फायदे हैं।

Answer 8

कई अनुप्रयोगों में, जैसे MsOffice (संस्करण 2000 या 2002 तक), प्रति कक्ष वर्णों की अधिकतम संख्या 255 थी। उन अनुप्रयोगों से प्रति क्षेत्र 255 से अधिक वर्णों को संभालने में सक्षम कार्यक्रमों से डेटा एक बुरे सपने में था। वर्तमान में, सीमा कम है और कम बाधा है।

Answer 9

0000 0000 -> यह एक 8-बिट बाइनरी नंबर है। एक अंक थोड़ा प्रतिनिधित्व करता है।

आप इस तरह गिनते हैं:

0000 0000 → (0)

0000 0001 → (1)

0000 0010 → (2)

0000 0011 → (3)

प्रत्येक बिट दो मानों में से एक हो सकता है: चालू या बंद। कुल उच्चतम संख्या गुणन द्वारा दर्शाई जा सकती है:

2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255

या

2^8 - 1. 

हम एक घटाते हैं क्योंकि पहली संख्या 0 है।

255 मानों का बहुत थोड़ा (कोई भी इरादा नहीं) पकड़ सकता है।

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

Answer 10

एक और कारण यह हो सकता है कि विंडोज पर बहुत पुराने डेटा एक्सेस पुस्तकालयों जैसे RDO और ADO (COM संस्करण ADO.NET) में आपको 255 से अधिक वर्ण वाले कॉलम से डेटा प्राप्त करने के लिए एक विशेष विधि, GetChunk को कॉल करना होगा। यदि आप एक varchar कॉलम को 255 तक सीमित करते हैं, तो यह अतिरिक्त कोड आवश्यक नहीं था।