نمایه سازی پایگاه داده موثر

نمایه سازی بانک اطلاعاتی موثر در یک پایگاه داده عادی تأثیر بیشتری نسبت به پرتاب منابع اضافی به سیستم خواهد داشت

پایگاه داده عادی چیست؟

از نظر عادی ، عادی سازی روند ساخت پایگاه های داده رابطه ای است به گونه ای که با شکستن و پیوند داده ها به بخش های کوچکتر از داده های قابل به روز شدن ، ازدیاد داده ها را کاهش می دهد.

این مقاله در درجه اول بر روی پایگاه های داده ای است که در یک ساختار عادی کار می کنند ، و منطقه ای را که اکثر مردم با آن آشنا هستند (یا می توانند تصور کنند) که معاملات مالی ، مشتریان و مخاطبین است ، مورد بررسی قرار می دهد.

چرا نرمال شده است؟

برخی از سطوح یا عادی سازی می تواند مقدار زیادی از پیشرفت را در بیشتر مجموعه های داده ایجاد کند ، و در حالی که دریاچه داده ها و پردازش داده های غیر عادی در برخی از جنبه های استفاده تجاری مورد توجه قرار گرفته است ، احتمالاً اکثر مشاغل از ذخیره داده های اصلی خود به نوعی شکل عادی بهره مند می شوند. همانطور که می تواند؛

سرعت بخشیدن به به روزرسانی ها (زیر را ببینید)
بازجویی از داده ها را آسان تر کنید
به طور معمول رد پای داده کوچکتر فراهم می کند
با هنجارهای صنعت مطابقت دارد

رویکرد ما

رویکرد استاندارد ما این است که به داده ها نگاه کنیم گویی که از سه طریق مختلف ذخیره شده اند و هنگام ساخت سیستم های جدید مبتنی بر SQL Server سعی می کنیم آنها را در طرح های مختلف نگه داریم.

این روش با مشتری های قبلی ما کار کرده است و ما حتی پیشرفت های قابل توجهی در سرعت ارائه دهندگان سیستم آنها نیز داشته ایم.

هدف ما این است که به زودی برای هر بخش یک مقاله فرعی جداگانه اضافه کنیم و بخشی را برای کاوش مفاهیم مربوط به گزارش خنثی سیستم بین چندین پایگاه داده اضافه کنیم.

نمای کلی فهرست

در حالی که SQL Server متمرکز است ، اصول یکسانی برای بسیاری از سیستم ها اعمال می شود. تعداد و انواع نمایه ها می توانند عملکرد خواندن و نوشتن را به طور مستقل بهبود یا کاهش دهند.

خوشه ای

شما در هر جدول به یک جدول محدود هستید ، و این نحوه ذخیره سازی داده ها بر روی دیسک را تعریف می کند.

به جداولي كه از اين نوع ايندكس داشته باشند ، جدول خوشه اي (Clustered Table) گفته مي شود و از مواردي كه فاقد آن هستند ، Heap گفته مي شود.

غیر خوشه ای

تقریباً می توانید این را به عنوان یک جدول جداگانه در نظر بگیرید که به هر سطر اشاره دارد ، اما در 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))

داده های تجاری

این سطح متوسط منطقه شامل حساب ها ، مشتریان و مخاطبین یا سایر مناطقی است که ممکن است توسط چیز دیگری ارجاع داده شود و همچنین نوع اطلاعات را ارجاع می دهد.

این سطح از نظر تصمیم گیری در مورد تعیین شاخص اصلی خود معمولاً سخت ترین است ، زیرا احتمالاً ترکیبی از رویکردهای مختلف خواهد بود.

در زیر جدول ایجاد جدول های آدرس ، مشتری و مخاطب آورده شده است. در این کد یک جدول اضافی (پیوستن) وجود دارد که به قسمتهای Client ، Address و Address می پیوندد و در اینجا ما یک فهرست خوشه ای ایجاد کرده ایم که متفاوت از جداول دیگر است. این بدان دلیل است که در اکثر برنامه ها ، این یک جدول فشرده برای خواندن است ، و ما می توانیم برای درج عملکرد ، افزایش حداقل را بپذیریم. اگر این برنامه ساخته شده توسط ما بود ، ما احتمالاً جزئیات تماس مشتری را به روشی مشابه جدا می کردیم.

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)

می پیوندد و گزارش می دهد

در پایگاه داده های خیالی بالا ، ما سعی کرده ایم زندگی واقعی را تا آنجا که ممکن است نشان دهیم. این به هیچ وجه رویکردی نیست که باید اتخاذ شود و شما در نهایت مسئول استفاده از اطلاعات فوق هستید.

همانطور که داده ها به رده سوم رفته اند ، تمرکز نمایه سازی به چگونگی خواندن داده ها از یک برنامه یا گزارش منتقل شده است ، و این بدون شک شامل پیوستن بین جداول و سایر نکاتی است که می تواند یا در این لیست گنجانده شود بندهای WHERE.