प्रत्येक कॉलम के लिए पूर्वनिर्धारित डेटा प्रकार सेट करके रिलेशनल डेटाबेस क्या प्राप्त करते हैं?

44

मैं अभी एक SQL डेटाबेस के साथ काम कर रहा हूं, और इसने मुझे हमेशा उत्सुक बनाया है, लेकिन Google खोजों में बहुत बदलाव नहीं होता है: सख्त डेटा प्रकार क्यों?

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

लेकिन मुझे समझ में नहीं आ रहा है कि इतने अलग-अलग डेटा प्रकार होने का क्या लाभ है :

क्यों mediumtext, longtextऔर text?
क्यों decimal, floatऔर int?
आदि।

डेटाबेस को यह बताने का क्या लाभ है "इस कॉलम में प्रविष्टियों में सादे पाठ डेटा के केवल 256 बाइट होंगे।" या "इस कॉलम में 16,777,215 बाइट तक की टेक्स्ट प्रविष्टियाँ हो सकती हैं"?

क्या यह एक प्रदर्शन लाभ है? यदि हां, तो हाथ मदद प्रदर्शन से पहले प्रवेश के आकार को क्यों जानता है? या बल्कि यह पूरी तरह से कुछ और है?

— जॉन डो
स्रोत

2

मुझे लगा कि यह प्रश्न पहले से ही यहां मौजूद होना चाहिए, लेकिन मैंने साइट की खोज की और कुछ भी उपयोगी नहीं पाया।

— जॉन डो

1

बहुत ही प्रासंगिक: joelonsoftware.com/2001/12/11/back-to-basics

— 8bittree

6

यदि आपके पास अलग decimal, floatऔर intप्रकार नहीं हैं, तो आप क्या 1 / 3करने की उम्मीद करेंगे ? किस बारे में 1.0 / 3.0? यदि आपको विश्वास है कि जब आप विभाजित हो सकता है columnAद्वारा columnBकि आप परिणाम आप उम्मीद मिल जाएगा?

— एंड्रयू का कहना है कि मोनिका

2

@ जॉंधो मुझे नहीं लगता कि यह कभी जरूरी होगा, लेकिन यह बहुत सुविधाजनक हो सकता है। मान लें कि आप एक बाधा को लागू करना चाहते हैं कि एक स्टोर की इन्वेंट्री उनकी मासिक अपेक्षित बिक्री के 5% से कम नहीं हो सकती है। या आप यह सुनिश्चित करना चाहते हैं कि प्रत्येक विभाग का कुल बजट कुल बजट का 20% से अधिक न हो। यह गणना किए गए स्तंभों में भी आ सकता है जो आप एक ही डेटाबेस का उपयोग करके कई अनुप्रयोगों में उसी तरह की गणना करना चाहते हैं।

— एंड्रयू का कहना है कि मोनिका

2

यह ध्यान देने योग्य है कि SQLite प्रति कॉलम एक पूर्वनिर्धारित प्रकार सेट नहीं करता है : "SQLite" टाइपलेस "है। इसका मतलब है कि आप किसी भी तालिका के किसी भी स्तंभ में किसी भी प्रकार के डेटा को संग्रहीत कर सकते हैं, भले ही उस स्तंभ के घोषित डेटा प्रारूप की परवाह किए बिना। "

— प्रधानमंत्री

50

एसक्यूएल एक सांख्यिकीय-टाइप भाषा है। इसका मतलब है कि आपको यह जानना होगा कि आप किस प्रकार का चर (या क्षेत्र, इस मामले में) का उपयोग करने से पहले कर सकते हैं। यह गतिशील रूप से टाइप की जाने वाली भाषाओं के विपरीत है, जहां यह जरूरी नहीं है।

इसके मूल में, SQL को रिलेशनल डेटाबेस इंजन में डेटा ( DDL ) और एक्सेस डेटा ( DML ) को परिभाषित करने के लिए डिज़ाइन किया गया है । स्टेटिक टाइपिंग इस प्रकार की प्रणाली में डायनेमिक टाइपिंग पर कई लाभ प्रस्तुत करता है।

अनुक्रमित , विशिष्ट रिकॉर्ड तक जल्दी पहुंचने के लिए उपयोग किया जाता है, जब आकार तय हो जाता है तो वास्तव में अच्छी तरह से काम करता है। एक क्वेरी पर विचार करें जो संभवतः एक सूचकांक का उपयोग करता है, संभवतः कई क्षेत्रों के साथ: यदि डेटा प्रकार और आकार समय से पहले जाना जाता है, तो मैं बहुत तेज़ी से सूचकांक में मूल्यों के खिलाफ अपने विधेय (जहां खंड या जोइन मानदंड) की तुलना कर सकता हूं और वांछित रिकॉर्ड तेजी से ढूंढ सकता हूं ।
दो पूर्णांक मानों पर विचार करें । एक गतिशील प्रकार की प्रणाली में, वे परिवर्तनशील आकार (सोच सकते हैं कि जावा BigInteger, या पायथन के अंतर्निहित मनमाना-सटीक पूर्णांक)। यदि मैं पूर्णांक की तुलना करना चाहता हूं, तो मुझे पहले उनकी बिट लंबाई जानने की जरूरत है। यह पूर्णांक तुलना का एक पहलू है जो काफी हद तक आधुनिक भाषाओं द्वारा छिपा हुआ है, लेकिन सीपीयू स्तर पर बहुत वास्तविक है। यदि आकार तय किए जाते हैं और समय से पहले जाना जाता है, तो प्रक्रिया से एक संपूर्ण चरण हटा दिया जाता है। फिर, डेटाबेस को संभव के रूप में जल्दी से लेनदेन के zillions प्रक्रिया करने में सक्षम होना चाहिए। गति राजा है।
SQL को 1970 के दशक में वापस डिजाइन किया गया था। माइक्रोकंप्यूटिंग के पहले के दिनों में, मेमोरी प्रीमियम पर थी। डेटा सीमित करने से भंडारण आवश्यकताओं को जांच में रखने में मदद मिली। यदि एक पूर्णांक कभी भी पिछले एक बाइट से नहीं बढ़ता है, तो इसके लिए अधिक भंडारण क्यों आवंटित करें? वह सीमित स्मृति के युग में जगह बर्बाद है। यहां तक कि आधुनिक समय में, उन अतिरिक्त व्यर्थ बाइट्स एक सीपीयू के कैश के प्रदर्शन को जोड़ सकते हैं और मार सकते हैं। याद रखें, ये डेटाबेस इंजन हैं जो प्रति सेकंड सैकड़ों लेन-देन कर सकते हैं, न कि केवल आपके छोटे विकास के माहौल में।
सीमित स्टोरेज की तर्ज पर, यह मेमोरी में एक पेज में एक भी रिकॉर्ड को फिट करने में सक्षम होने में मददगार है। एक बार जब आप एक पृष्ठ पर जाते हैं, तो अधिक पृष्ठ गलतियाँ और अधिक धीमी मेमोरी एक्सेस होती हैं। नए इंजनों में इस मुद्दे को कम करने के लिए अनुकूलन हैं, लेकिन यह अभी भी है। उचित रूप से डेटा साइज़ करके, आप इस जोखिम को कम कर सकते हैं।
आधुनिक समय में Moreso, SQL का उपयोग ORM या ODBC या किसी अन्य परत के माध्यम से अन्य भाषाओं में प्लग करने के लिए किया जाता है । इनमें से कुछ भाषाओं में मजबूत, स्थिर प्रकार की आवश्यकता के बारे में नियम हैं। अधिक सख्त आवश्यकताओं के अनुरूप यह सबसे अच्छा है, क्योंकि गतिशील रूप से टाइप की जाने वाली भाषाएं स्थिर प्रकार के साथ दूसरे तरीके से आसान तरीके से निपट सकती हैं।
SQL स्थैतिक टाइपिंग का समर्थन करता है क्योंकि डेटाबेस इंजन को प्रदर्शन के लिए इसकी आवश्यकता होती है, जैसा कि ऊपर दिखाया गया है।

यह ध्यान रखना दिलचस्प है कि SQL के कार्यान्वयन ऐसे हैं जो दृढ़ता से टाइप नहीं किए जाते हैं। SQLite शायद इस तरह के एक रिलेशनल डेटाबेस इंजन का सबसे लोकप्रिय उदाहरण है। तब फिर से, इसे एकल सिस्टम पर एकल-थ्रेडेड उपयोग के लिए डिज़ाइन किया गया है, इसलिए प्रदर्शन संबंधी चिंताओं का उदाहरण नहीं दिया जा सकता है जैसे कि एक उद्यम ओरेकल डेटाबेस प्रति मिनट लाखों अनुरोधों को सेवित करता है।

— gruszczy
स्रोत

SQLite में डेटाटाइप्स होते हैं जो संख्यात्मक और टेक्स्ट डेटा के बीच अंतर करते हैं, लेकिन डेटा भंडारण के केवल 5 "वर्ग" हैं: sqlite.org/datatype3.html

— FrustratedWithFormsDesigner

1

@FrustratedWithFormsDesigner मुझे पता है, लेकिन यह अभी भी SQL सर्वर, Oracle, या PostgreSQL जैसे इंजनों के समान सख्त नहीं है।

न केवल एसक्यूएल सांख्यिकीय रूप से टाइप किया जाता है - चेक बाधाओं की उपस्थिति के कारण, यह प्रभावी रूप से शोधन प्रकारों का समर्थन करता है।

— गार्डेनहेड

4

यद्यपि पहली गोली में निहित है Indexes, अधिक मूल रूप से कहा गया है: डेटा प्रकार होने से डेटाबेस इंजन को डेटा की समझ बनाने की अनुमति देता है , तुलना करने के लिए (बड़ी / छोटी संख्या, पहले / बाद की तारीख-बार, वर्णमाला में / उसके पहले)। और इसलिए छाँटने और क्वेरी करने में सक्षम बनाता है ।

— बेसिल बोर्के

इसलिए यदि आकार महत्वपूर्ण हैं ... और sql को पहले से जानना आवश्यक है ... "Zillion" लेनदेन का सटीक आकार क्या है?

— वर्नरसीडी

24

पहला: सादा पाठ द्विआधारी है (यह UTF8 या ASCII वर्ण "0" और "1" भी नहीं है, लेकिन वास्तविक / बंद है)

कहा कि, कुछ कारण हैं:

व्यवसाय / डिज़ाइन की बाधाएँ: PERSON तालिका के ऊँचाई स्तंभ में संख्या 7626355112 की अनुमति देना गलत होगा। एक INVOICE के DATE कॉलम में "Howya" की अनुमति देना गलत होगा।
कम त्रुटि प्रवण कोड: आपको यह सुनिश्चित करने के लिए कोड लिखने की आवश्यकता नहीं है कि डेट कॉलम से प्राप्त डेटा वास्तव में एक तारीख है। यदि स्तंभ प्रकार गतिशील थे, तो आपको उन्हें पढ़ते समय कई प्रकार की जांच करनी होगी।
कम्प्यूटिंग दक्षता: यदि कोई कॉलम INTEGER का है, और आप उसे () SUM करते हैं, तो RDBMS को फ्लोटिंग पॉइंट अंकगणित लागू नहीं करना है।
भंडारण क्षमता: यह बताते हुए कि एक स्तंभ VARCHAR है (10) RDBMS को अधिक सटीक रूप से स्थान आवंटित करने देता है।
प्रासंगिक अखंडता और एकता: पीके (या FKs) एक तालिका को फ़्लोट्स की अनुमति नहीं देनी चाहिए, क्योंकि फ्लोटिंग पॉइंट समानता मुश्किल है, इसलिए आपको उन्हें गैर-फ़्लोट प्रकार, जैसे वर्ण या पूर्णांक में घोषित करना चाहिए।
मौजूद RDBMSs व्हिट डायनेमिक (सख्त नहीं) स्तंभ प्रकार (SQLite) । यह "प्रकार आत्मीयता" की अवधारणा का उपयोग करता है, जबकि अभी भी आपको शिकायत किए बिना किसी भी कॉलम में लगभग कुछ भी सम्मिलित करने की अनुमति देता है। ऐसे व्यापार-व्यापार हैं जिनकी चर्चा यहाँ नहीं की जाएगी। इस प्रश्न को देखें ।

— ट्यूलेंस कोर्डोवा
स्रोत

8

ऐसा इसलिए है कि डेटाबेस में जो अंतर्निहित कोड लिखा गया है, वह निश्चित आकार के रिकॉर्ड को आवंटित और उपयोग कर सकता है, अगर यह जानता है कि किसी विशिष्ट क्षेत्र में पाठ के 0 से 256 वर्ण हो सकते हैं, तो वह इसे स्टोर करने के लिए 256 बाइट्स के ब्लॉक को आवंटित कर सकता है।

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

— स्टीव बार्न्स
स्रोत

यदि केवल सभी उत्तर इस संक्षिप्त और बिंदु के हो सकते हैं ...

— डैरेन रिंगर

6

जब किसी डेटाबेस के कॉलम को परिभाषित प्रकार दिए जाते हैं, तो आमतौर पर बिट्स में एक निश्चित आकार होने के लिए प्रकारों को स्वयं परिभाषित किया जाता है। नतीजतन:

1) जब डेटाबेस इंजन एक तालिका में पंक्तियों को ट्रेस कर रहा होता है, तो यह निर्धारित करने के लिए कोई फैंसी पार्सिंग नहीं करना पड़ता है कि प्रत्येक रिकॉर्ड कहाँ समाप्त होता है, यह सिर्फ यह जान सकता है कि प्रत्येक पंक्ति में 32 बाइट्स हैं, और इसलिए अगला रिकॉर्ड वर्तमान रिकॉर्ड स्थान पर 32 बाइट्स जोड़ने के लिए पर्याप्त है।

2) जब एक पंक्ति के भीतर एक क्षेत्र को देखते हैं, तो उस क्षेत्र के लिए एक सटीक ऑफसेट को फिर से कुछ भी पार्स किए बिना जानना संभव है, इसलिए स्तंभ लुकअप एक संभावित महंगा डेटा प्रसंस्करण एक के बजाय एक सरल अंकगणितीय ऑपरेशन है।

— उपयोगकर्ता नहीं मिला
स्रोत

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

— ज़ेनिलॉगिक्स

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

— यूजरनॉटफाउंड

3

आपने पूछा कि DBMS में स्थिर डेटा प्रकार क्यों होते हैं।

देखने की गति। DBMS का संपूर्ण बिंदु इससे कहीं अधिक डेटा स्टोर करना है जितना आप संभवतः किसी प्रोग्राम में लोड कर सकते हैं। सोचो "पिछले दस वर्षों में दुनिया में उत्पन्न सभी क्रेडिट कार्ड पर्ची"। ऐसे डेटा को कुशलतापूर्वक खोजने के लिए, निश्चित लंबाई के डेटा प्रकार सहायक होते हैं। यह विशेष रूप से संरचित डेटा के लिए सही है जैसे दिनांक टिकट और खाता संख्या। यदि आप जानते हैं कि आप समय से पहले क्या काम कर रहे हैं, तो कुशल इंडेक्स में लोड करना आसान है।
अखंडता और बाधाओं। यदि डेटा प्रकार निश्चित हैं, तो डेटा को साफ रखना आसान है।
इतिहास। RDBMSs तब शुरू हुए जब कंप्यूटरों में रैम की कुछ मेगाबाइट्स थीं, और टेराबाइट-स्केल स्टोरेज काफी महंगा था। एक तालिका की प्रत्येक पंक्ति में एक दर्जन बाइट्स सहेजने से उन परिस्थितियों में हजारों डॉलर और समय की बचत हो सकती है।
ग्राहक आधार का अभिशाप। RDBMS आज बहुत जटिल, अत्यधिक अनुकूलित, सॉफ्टवेयर पैकेज हैं, और वे दशकों से डेटा जमा करने के लिए उपयोग में हैं। वे परिपक्व हैं। वे काम करते हैं। बड़े पैमाने पर डेटा हानि के परिणामस्वरूप RDBMS क्रैश इन दिनों vaninshingly दुर्लभ है। अधिक लचीली डेटा टाइपिंग प्रणाली के साथ किसी चीज़ पर स्विच करना अधिकांश संगठनों के लिए लागत या जोखिम के लायक नहीं है।

सादृश्य: यह स्पष्ट हो सकता है कि एक संकीर्ण रेल गेज पर शहरी मेट्रो सिस्टम बेहतर (शांत, तेज, अधिक शक्ति-कुशल) काम करेगा। लेकिन आप उन सुधारों को महसूस करने के लिए न्यूयॉर्क सिटी मेट्रो प्रणाली में सभी रेल को कैसे बदलेंगे? आप नहीं हैं, इसलिए आपके पास जो कुछ भी है उसे आप अनुकूलित करते हैं।

— ओ। जोन्स
स्रोत

3

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

क्यों मध्यम, longtext, और पाठ?

निश्चित नहीं है कि आपका उपयोग करने वाला कौन सा डेटाबेस है, इसलिए मुझे अनुमान लगाना होगा: मुझे लगता है कि इनमें से दो डेटाटिप्स की ऊपरी सीमाएं हैं, उनमें से एक नहीं है। ऊपरी सीमा वाले पाठ के लिए डेटाटिप्स का उपयोग करना डेटाबेस को बताता है कि प्रत्येक रिकॉर्ड के लिए कितना संग्रहण स्थान की आवश्यकता होगी। यह भी संभव है कि कुछ डेटाबेस में बड़े (संभवतः असीमित) पाठ बनाम छोटे निश्चित-लंबाई वाले पाठ के भंडारण के विभिन्न तरीके हो सकते हैं (यह डेटाबेस से भिन्न हो सकता है, अपने बारे में देखने के लिए अपने मैनुअल की जांच करें)।

दशमलव, फ्लोट और इंट क्यों?

परिशुद्धता के विभिन्न स्तरों के लिए अलग-अलग मात्रा में भंडारण की आवश्यकता होती है, और हर उपयोग के लिए सटीक रूप से उच्चतम डिग्री की आवश्यकता होती है। उदाहरण के लिए, यहां देखें: https://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF50950

ओरेकल के पास अलग-अलग संख्यात्मक प्रकार की बहुत सी विभिन्न प्रकार की भंडारण आवश्यकताएं हैं और सटीक स्तर और संख्या के आकार के संदर्भ में विभिन्न क्षमताओं का प्रतिनिधित्व किया जा सकता है।

— FrustratedWithFormsDesigner
स्रोत

2

कुछ हद तक, यह ऐतिहासिक है।

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

ऐसी फ़ाइल में कुछ अनुक्रमित जोड़ें और आपके पास एक रिलेशनल डेटाबेस की शुरुआत है।

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

कभी-कभी व्यापार तर्क के कुछ बिट को लागू करने में मदद करने के लिए एक क्षेत्र के लिए एक विशिष्ट आकार निर्धारित करना उपयोगी होता है - उत्तर अमेरिकी फोन नंबर के लिए 10 अंक। ज्यादातर समय यह सिर्फ कंप्यूटिंग विरासत का एक सा है।

— Zenilogix
स्रोत

1

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

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

— supercat
स्रोत

1

वेब डेवलपर के रूप में आप जो करते हैं, उसके लिए "हूड के तहत" क्या हो रहा है, यह समझने की कोई आवश्यकता नहीं है। हालांकि, कई बार यह मदद करता है।

डेटाबेस को यह बताने का क्या लाभ है "इस कॉलम में प्रविष्टियों में सादे पाठ डेटा के केवल 256 बाइट होंगे।" या "इस कॉलम में 16,777,215 बाइट तक की टेक्स्ट प्रविष्टियाँ हो सकती हैं"?

जैसा कि आप संदेह करते हैं, इसका कारण दक्षता के साथ करना है। अमूर्त रिसाव । SELECT author FROM booksजब तालिका में सभी फ़ील्ड का आकार ज्ञात हो, तो क्वेरी बहुत तेज़ी से चल सकती है।

जैसा कि जोएल कहते हैं,

रिलेशनल डेटाबेस कैसे लागू होता है SELECT author FROM books? एक संबंधपरक डेटाबेस में, तालिका में प्रत्येक पंक्ति (जैसे किताबें तालिका) बाइट्स में बिल्कुल समान लंबाई होती है, और पंक्ति की शुरुआत से प्रत्येक फ़ील्ड हमेशा एक निश्चित ऑफसेट पर होती है। इसलिए, उदाहरण के लिए, यदि पुस्तक तालिका में प्रत्येक रिकॉर्ड 100 बाइट्स लंबा है, और लेखक फ़ील्ड 23 पर है, तो बाइट 23, 123, 223, 323 इत्यादि पर संग्रहीत लेखक हैं, कोड को स्थानांतरित करने के लिए कोड क्या है। इस क्वेरी के परिणाम में अगला रिकॉर्ड? असल में, यह है:

pointer += 100;

एक सीपीयू निर्देश। Faaaaaaaaaast।

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

— ट्रिग
स्रोत