فهرسة فعالة لقواعد البيانات

سيكون للفهرسة الفعالة لقاعدة البيانات في قاعدة البيانات العادية تأثير أكبر على الأداء من مجرد إلقاء موارد إضافية على النظام

ما هي قاعدة البيانات الموحدة؟

من منظور الشخص العادي ، التطبيع هو عملية هيكلة قواعد البيانات العلائقية بطريقة تقلل من تكرار البيانات عن طريق تقسيم البيانات وربطها إلى أجزاء أصغر من البيانات القابلة للتحديث.

تركز هذه المقالة بشكل أساسي على قواعد البيانات التي تعمل في بنية طبيعية ، وسوف تستكشف منطقة يعرفها معظم الناس (أو يمكنهم تخيلها) وهي المعاملات المالية والعملاء وجهات الاتصال.

لماذا تطبيع؟

يمكن لبعض المستويات أو التطبيع أن يجلب قدرًا كبيرًا من التحسين لمعظم مجموعات البيانات ، وبينما تكتسب بحيرات البيانات ومعالجة البيانات غير الطبيعية زخمًا في بعض جوانب استخدام الأعمال ، فمن المحتمل أن تستفيد معظم الشركات من تخزين بياناتها الرئيسية في شكل ما عادي بقدر ما تستطيع

تسريع التحديثات (انظر أدناه)
تسهيل استجواب البيانات
عادة ما يوفر بصمة بيانات أصغر
يتوافق مع معايير الصناعة

نهجنا

يتمثل نهجنا القياسي في النظر إلى البيانات كما لو كانت مخزنة بثلاث طرق مختلفة ، وعند إنشاء أنظمة جديدة قائمة على SQL Server ، نحاول الاحتفاظ بها في مخططات مختلفة.

لقد نجح هذا النهج مع عملائنا السابقين ، وقمنا بتوسيع تحسينات السرعة الكبيرة لموفري النظام.

سنهدف إلى إضافة مقالة فرعية منفصلة لكل قسم في الوقت المناسب ، وإضافة قسم لاستكشاف المفاهيم حول التقارير المحايدة للنظام بين قواعد البيانات المتعددة.

نظرة عامة على الفهرس

بينما يركز SQL Server ، تنطبق نفس المبادئ على العديد من الأنظمة المختلفة. يمكن لعدد وأنواع الفهارس تحسين أو تقليل أداء القراءة والكتابة بشكل مستقل.

عنقودية

أنت مقيد بواحد لكل جدول ، وهذا يحدد كيفية تخزين البيانات على القرص.

تسمى الجداول التي تحتوي على فهرس من هذا النوع جدول مجمع ، وتلك التي لا تحتوي على فهرس يُشار إليها باسم كومة.

غير عنقودية

يمكنك تقريبًا التفكير في هذا كجدول منفصل يشير إلى كل صف ، ولكن في SQL Server ، يتغير التخزين الفعلي اعتمادًا على نوع الجدول (مجمع / كومة)

التفرد

يمكن أن يكون كلا هذين الفهرين فريدين ، وعند استخدامهما بشكل صحيح ، يمكن أن يؤدي ذلك إلى تحسينات حقيقية في كيفية تخزين بياناتك.

فهارس مركبة

يمكن أن تستخدم كافة الفهارس عمودًا واحدًا أو أكثر ، ولكن يجب أن يكون الفهرس العنقودي أقل من 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)

ينضم وإعداد التقارير

في قاعدة البيانات الخيالية أعلاه ، حاولنا تمثيل الحياة الواقعية بأكبر قدر ممكن. هذا ليس بأي حال من الأحوال نهجًا يجب اتباعه ، وأنت مسؤول في النهاية عن كيفية استخدامك للمعلومات الواردة أعلاه.

نظرًا لأن البيانات قد انتقلت إلى المستوى الثالث ، فقد تم نقل تركيز الفهرسة إلى كيفية قراءة البيانات من تطبيق أو تقرير ، وسيشمل هذا دائمًا الصلات بين الجداول وأي نقاط يمكن أو سيتم تضمينها في بنود أين.