प्रभावी डेटाबेस अनुक्रमण

एक सामान्यीकृत डेटाबेस में प्रभावी डेटाबेस अनुक्रमण का सिस्टम पर अतिरिक्त संसाधनों को फेंकने की तुलना में अधिक प्रदर्शन प्रभाव होगा

सामान्यीकृत डेटाबेस क्या है?

आम आदमी के शब्दों में, सामान्यीकरण एक तरह से संबंधपरक डेटाबेस को संरचित करने की प्रक्रिया है जो डेटा को तोड़कर और अद्यतन करने योग्य डेटा के छोटे टुकड़ों में जोड़कर डेटा अतिरेक को कम करता है।

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

सामान्यीकृत क्यों?

कुछ स्तर या सामान्यीकरण अधिकांश डेटासेट में भारी मात्रा में वृद्धि ला सकता है, और जब डेटा लेक और असामान्य डेटा प्रोसेसिंग व्यावसायिक उपयोग के कुछ पहलुओं में कर्षण प्राप्त कर रहा है, तो अधिकांश व्यवसायों को संभवतः अपने मुख्य डेटा को किसी प्रकार के सामान्य रूप में संग्रहीत करने से लाभ होगा। के रूप में यह कर सकता है;

अपडेट तेज करें (नीचे देखें)
डेटा पूछताछ के लिए इसे आसान बनाएं
आम तौर पर एक छोटा डेटा फ़ुटप्रिंट प्रदान करता है
उद्योग के मानदंडों के अनुरूप

हमारा दृष्टिकोण

हमारा मानक दृष्टिकोण डेटा को देखने के लिए है जैसे कि इसे तीन अलग-अलग तरीकों से संग्रहीत किया जाता है, और नए SQL सर्वर आधारित सिस्टम का निर्माण करते समय हम उन्हें अलग-अलग स्कीमा में रखने का प्रयास करते हैं।

इस दृष्टिकोण ने हमारे पिछले ग्राहकों के साथ काम किया है, और हमने उनके सिस्टम प्रदाताओं के लिए पर्याप्त गति सुधार भी बढ़ाया है।

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

सूचकांक अवलोकन

जबकि SQL सर्वर केंद्रित है, वही सिद्धांत कई अलग-अलग प्रणालियों पर लागू होते हैं। इंडेक्स की संख्या और प्रकार स्वतंत्र रूप से पढ़ने और लिखने के प्रदर्शन में सुधार या कमी कर सकते हैं।

क्लस्टर किया गया

आप प्रति तालिका एक तक सीमित हैं, और यह परिभाषित करता है कि डिस्क पर डेटा कैसे संग्रहीत किया जाता है।

इस प्रकार की अनुक्रमणिका वाली तालिकाएँ क्लस्टर तालिका कहलाती हैं, और जिनके पास नहीं है उन्हें हीप कहा जाता है।

गैर-क्लस्टर

आप इसे लगभग एक अलग तालिका के रूप में सोच सकते हैं जो प्रत्येक पंक्ति के संदर्भ में है, हालांकि SQL सर्वर में, वास्तविक संग्रहण तालिका प्रकार (क्लस्टर/ढेर) पर निर्भर करता है।

विशिष्टता

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

यौगिक सूचकांक

सभी इंडेक्स एक या अधिक कॉलम का उपयोग कर सकते हैं, हालांकि क्लस्टर इंडेक्स को 900 बाइट्स से कम होना चाहिए।

रुको, प्राथमिक कुंजी के बारे में क्या?

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

एक विदेशी कुंजी वास्तव में किसी भी अद्वितीय अनुक्रमणिका को संदर्भित कर सकती है, और यहां तक कि एकाधिक कॉलम भी संदर्भित कर सकती है।

संदर्भ डेटा

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

मानक उपयोग

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

Reference Tables

CREATE SCHEMA RefGOCREATE TABLE Ref.AddressType(AddressTypeID INT IDENTITY(1,1) CONSTRAINT PK_Ref_AddressType PRIMARY KEY CLUSTERED,AddressTypeName NVARCHAR(100))CREATE TABLE Ref.ClientType(ClientTypeID INT IDENTITY(1,1) CONSTRAINT PK_Ref_Client PRIMARY KEY CLUSTERED,ClientTypeName NVARCHAR(100))CREATE TABLE Ref.ContactType(ContactTypeID INT IDENTITY(1,1) CONSTRAINT PK_Ref_ContactType PRIMARY KEY CLUSTERED,ContactTypeName NVARCHAR(100))CREATE TABLE Ref.TransactionType(TransactionTypeID INT IDENTITY(1,1) CONSTRAINT PK_Ref_TransactionType PRIMARY KEY CLUSTERED,TransactionTypeName NVARCHAR(100))

व्यापार डेटा

इस मध्य स्तर के क्षेत्र में खाते, ग्राहक और संपर्क या अन्य क्षेत्र शामिल होंगे जिन्हें किसी अन्य चीज़ द्वारा संदर्भित किया जा सकता है, और प्रकार की जानकारी को भी संदर्भित किया जा सकता है।

यह तय करने के मामले में कि आपका मुख्य सूचकांक कहाँ रखा जाए, इस स्तर पर काम करना आम तौर पर सबसे कठिन होता है, क्योंकि यह संभवतः विभिन्न दृष्टिकोणों का मिश्रण होगा।

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

Business Tables

CREATE SCHEMA BusGOCREATE TABLE Bus.[Address](AddressID INT CONSTRAINT PK_Bus_Address PRIMARY KEY CLUSTERED,AddressName NVARCHAR(100),AddressTypeID INT CONSTRAINT FK_Bus_Client_AddressTypeID FOREIGN KEY REFERENCES Ref.AddressType(AddressTypeID),AddressLine1 NVARCHAR(MAX)--Use more detail as required...)CREATE TABLE Bus.Client(ClientID INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,ClientName NVARCHAR(100),ClientType INT CONSTRAINT FK_Bus_Client_ClientType FOREIGN KEY REFERENCES Ref.ClientType(ClientTypeID))--Use one table to handle all client addressesCREATE TABLE Bus.ClientAddress(ClientAddressID INT IDENTITY(1,1) CONSTRAINT PK_Bus_ClientAddressID PRIMARY KEY NONCLUSTERED,AddressTypeID INT,ClientID INT,AddressID INT,CONSTRAINT UQ_Bus_ClientAddress UNIQUE NONCLUSTERED (ClientID,AddressTypeID)--This ensures one type per client, can slow down inserts slightly)CREATE UNIQUE CLUSTERED INDEX CDX_Bus_ClientAddress ON Bus.ClientAddress(ClientID,AddressTypeID,AddressID)CREATE TABLE Bus.Contact(ContactID INT IDENTITY(1,1) CONSTRAINT PK_Bus_Contact PRIMARY KEY CLUSTERED,ContactName NVARCHAR(100),ContactTypeID INT CONSTRAINT FK_Bus_Contact_ContactTypeID FOREIGN KEY REFERENCES Ref.ContactType(ContactTypeID)--Could be broken out into a joining table if desired--Use more detail as required...)

लेन-देन संबंधी डेटा

इस क्षेत्र में नोट, भुगतान और आदेश जैसी चीजें शामिल हैं, और आम तौर पर व्यवसाय और संदर्भ दोनों क्षेत्रों की ओर इशारा करते हैं।

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

Transactional Tables

CREATE SCHEMA TraGOCREATE TABLE Tra.[Transaction](TransactionID INT IDENTITY(1,1) CONSTRAINT PK_Tra_TransactionID PRIMARY KEY NONCLUSTERED,TransactionDate DATETIME CONSTRAINT DF_Tra_Transaction_TransactionDate DEFAULT GETUTCDATE(),--Use GETDATE() for local time.TransactionTypeID INT CONSTRAINT FK_Tra_Transaction_TransactionTypeID FOREIGN KEY REFERENCES Ref.TransactionType(TransactionTypeID),ClientID INT CONSTRAINT FK_Tra_Transaction_ClientID FOREIGN KEY REFERENCES Bus.Client(ClientID),ContactID INT CONSTRAINT FK_Tra_Transaction_ContactID FOREIGN KEY REFERENCES Bus.Contact(ContactID),TransactionAmount DECIMAL(18,2)--Use more detail as required...)CREATE CLUSTERED INDEX CDX_Tra_Transaction ON Tra.[Transaction](TransactionDate,TransactionTypeID,ClientID,ContactID)

जॉइन और रिपोर्टिंग

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

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

अग्रिम पठन

अनुक्रमणिका का पुनर्निर्माण या पुनर्व्यवस्थित करें