Etkili Veritabanı İndeksleme

Normalleştirilmiş bir veritabanında Etkili Veritabanı İndeksleme, sisteme ek kaynaklar atmaktan daha fazla performans etkisine sahip olacaktır.

Normalleştirilmiş Veritabanı nedir?

Layman'ın terimleriyle, normalleştirme, ilişkisel veritabanlarını, verileri parçalayarak ve daha küçük güncellenebilir veri parçalarına bağlayarak veri fazlalığını azaltacak şekilde yapılandırma sürecidir.

Bu makale öncelikle normalleştirilmiş bir yapıda çalışan veritabanlarına odaklanmaktadır ve çoğu insanın aşina olduğu (veya hayal edebileceği) bir alanı, yani finansal işlemler, müşteriler ve ilgili kişileri keşfedecektir.

Neden Normalleştirildi?

Bir seviye veya normalleştirme, çoğu veri kümesine büyük miktarda iyileştirme getirebilir ve veri gölleri ve normalleştirilmemiş veri işleme, iş kullanımının bazı yönlerinde çekiş kazanırken, çoğu işletme, ana verilerinin bir tür normal biçimde depolanmasından büyük olasılıkla fayda sağlayacaktır. olabildiğince;

Güncellemeleri hızlandırın (aşağıya bakın)
Veri sorgulamayı kolaylaştırın
Normalde daha küçük bir veri ayak izi sağlar
Endüstri normlarına uygundur

Bizim yaklaşımımız

Standart yaklaşımımız, verilere sanki üç farklı şekilde saklanıyormuş gibi bakmak ve yeni SQL Server tabanlı sistemler kurarken onları farklı şemalarda tutmaya çalışıyoruz.

Bu yaklaşım önceki müşterilerimizde işe yaradı ve sistem sağlayıcılarına önemli hız iyileştirmeleri bile ekledik.

Zaman içinde her bölüm için ayrı bir alt makale eklemeyi ve birden çok veritabanı arasında sistemden bağımsız raporlama ile ilgili kavramları keşfetmek için bir bölüm eklemeyi hedefleyeceğiz.

Dizine Genel Bakış

SQL Server odaklanmış olsa da, aynı ilkeler birçok farklı sistem için geçerlidir. Dizinlerin sayısı ve türleri, okuma ve yazma performansını bağımsız olarak iyileştirebilir veya azaltabilir.

kümelenmiş

Tablo başına bir taneyle sınırlandırılırsınız ve bu, verilerin diskte nasıl depolandığını tanımlar.

Bu türden bir dizine sahip tablolara Kümelenmiş Tablo, olmayanlara Yığın adı verilir.

Kümelenmemiş

Bunu neredeyse her satıra atıfta bulunan ayrı bir tablo olarak düşünebilirsiniz, ancak SQL Server'da gerçek depolama, tablo türüne bağlı olarak değişir (kümelenmiş/yığın)

benzersizlik

Bu dizinlerin her ikisi de benzersiz olabilir ve doğru kullanıldığında, bu, verilerinizi saklama şeklinize bazı gerçek iyileştirmeler getirebilir.

Bileşik İndeksler

Tüm dizinler bir veya daha fazla sütun kullanabilir, ancak kümelenmiş bir dizinin 900 baytın altında olması gerekir.

Bekle, peki ya Birincil Anahtar?

İnsanlar bir "Birincil Anahtar"dan bahsederken, genellikle "Benzersiz Kümelenmiş Dizin"den bahsederler ve pek çok kişi bunu otomatik olarak her seferinde bir artan tamsayı tabanlı bir kimlik alanı içindeki bir tabloda saklar. kayıt oluşturulur, buna daha sonra bir Yabancı Anahtar kullanılarak başka bir tablo tarafından başvurulabilir.

Bir Yabancı Anahtar aslında herhangi bir benzersiz dizine başvurabilir ve hatta birden çok sütuna başvurabilir.

Referans verisi

Bu alan, daha sonra zincirin aşağısındaki başka bir tablo tarafından referans verilen Hesap Türleri ve Ödeme Türleri gibi tüm üst düzey bilgileri içermelidir. Buradaki avantaj, normalleştirilmiş bir veritabanındaki birden çok satırı değiştirmek için tek bir güncellemenin kullanılabilmesidir, normalleştirilmemişse her satırı güncellemesi gerekir.

Standart Kullanım

Genel olarak, ideal olarak benzersiz bir kümelenmiş dizin olarak bir kimlik sütunu kullanırız. Aşağıda dört tablo ve bir şema oluşturacağız.

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))

İş verisi

Bu orta düzey alan, Hesaplar, Müşteriler ve İlgili Kişiler veya başka bir şey tarafından başvurulabilecek diğer alanları içerir ve ayrıca tür bilgilerine başvurur.

Bu seviye, muhtemelen farklı yaklaşımların bir karışımı olacağından, ana indeksinizi nereye koyacağınıza karar verme açısından normalde üzerinde çalışılması en zor olan seviyedir.

Adres, Müşteri ve İletişim tablolarının oluşturulacağı tablo aşağıdadır. Bu kodda İstemci, Adres ve Adres tipi alanlarını birleştiren ek bir (birleştirme) tablo vardır ve burada diğer tablolardan farklı çalışan kümelenmiş bir dizin oluşturduk. Bunun nedeni, çoğu uygulamada bunun yoğun bir okuma tablosu olması ve ekleme performansında minimum bir artışı kabul edebilmemizdir. Bu bizim tarafımızdan oluşturulmuş bir uygulama olsaydı, muhtemelen müşteri iletişim bilgilerini benzer şekilde ayırırdık.

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...)

İşlem Verileri

Bu alan, notlar, ödemeler ve siparişler gibi şeyleri içerir ve genellikle hem iş hem de referans alanlarına işaret eder.

Benzersiz anahtarlar tanımlama için iyi olsa da, genel kullanımda okuma süreleri etkileneceğinden, muhtemelen diskteki verileri bu şekilde sıralamak istemezsiniz. Aşağıda oluşturulmuş sadece bir tablo var, ancak size bir fikir vermesi gerekir.

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)

Katılımlar ve Raporlama

Yukarıdaki kurgusal veri tabanında mümkün olduğu kadar gerçek hayata yakın bir şekilde temsil etmeye çalıştık. Bu kesinlikle alınması gereken bir yaklaşım değildir ve yukarıdaki bilgileri nasıl kullandığınızdan nihai olarak siz sorumlusunuz.

Veriler üçüncü katmana geçtikçe, indeksleme odağı, verilerin bir uygulamadan veya rapordan nasıl okunacağına kaydırıldı ve bu, her zaman tablolar arasındaki birleştirmeleri ve dahil edilebilecek veya dahil edilebilecek herhangi bir noktayı içerecektir. WHERE cümleleri.

Daha fazla okuma

Dizinleri yeniden oluşturun veya yeniden düzenleyin