Etkili tablolar oluşturma

8 dakika

Etkili tablo tasarımı, tüm veritabanlarının temelini oluşturur. Tablolar verilerinizi yapılandırarak sorgularınızın bilgilere ne kadar verimli bir şekilde erişip bunları değiştirdiğini belirler.

Tablo tasarlama ve oluşturma

Tablolar, ilişkisel veritabanlarının temel yapı taşlarıdır ve verileri varlıkları ve özniteliklerini temsil eden satırlar ve sütunlar halinde düzenler. İlişkisel sistemlerde tablolar, işlem verilerini depolamak, yabancı anahtarlar aracılığıyla ilişkileri zorlamak ve sorgular ve raporlama için temel sağlamak için yapıyı tanımlar.

Çok boyutlu analizler için tablolar, ölçülebilir olayları ve analiz bağlamı sağlayan boyut tablolarını depolayan olgu tabloları görevi görür. Veri türleri, sütun boyutlandırma, kısıtlamalar ve ilişkiler gibi tablolar oluştururken aldığınız tasarım kararları, hem operasyonel hem de analitik iş yüklerinde depolama verimliliğini, sorgu performansını, veri bütünlüğünü ve ölçeklenebilirliği doğrudan etkiler.

Uygun veri türlerini seçin

Veri türleri, veritabanınızı etkileyen temel kararlardır. Yanlış seçim depolamanın boşa harcanmasına, düşük performansa, veri kaybına veya uygulama hatalarına yol açabilir. Kolayca yeniden düzenleyebileceğiniz uygulama kodundan farklı olarak, üretim veritabanlarındaki sütun veri türlerini değiştirmek genellikle tablo yeniden derlemesi gerektirir ve bu da büyük tablolar için çalışmama süresi anlamına gelebilir.

İlk şemayı tasarlarken uygun veri türlerini seçin. Bu, doğru şemayı elde etmek için en kolay zamandır. Ayrıca, aşağıdaki durumlarda veri türlerini dikkatli bir şekilde göz önünde bulundurun:

Kesinlik önemli olan verileri depoluyorsunuz.
Depolama maliyetlerinin çarpıldığı yüksek hacimli tablolarla çalışıyorsunuz
Daha küçük türlerle daha hızlı performans gösteren sık sorgulanan sütunlar tanımlıyorsunuz

Yaygın veri türlerini keşfetme

Uygun veri türleri depolamayı, performansı ve işlemleri etkiler:

Tür Kategorisi	Veri Türleri	Depolama Boyutu	Kullanım Yönergeleri	Example
Numeric	`INT`, `BIGINT`, `DECIMAL`, `FLOAT`	4 bayt, 8 bayt, değişir	Aralık ve hassasiyet gereksinimlerine göre tercihlerinizi belirleyin	`Quantity INT`, `Revenue DECIMAL(10,2)`, `Population BIGINT`
String	`VARCHAR`, `CHAR`, `NVARCHAR`	1 bayt/karakter, sabit, 2 bayt/karakter	Değişken uzunluklu veriler için, `VARCHAR` sabit uzunluk için, `CHAR` Unicode için kullanın `NVARCHAR`	`Email VARCHAR(100)`, `CountryCode CHAR(2)`, `ProductName NVARCHAR(100)`
Tarih/Saat	`DATE`, `DATETIME2`, `DATETIMEOFFSET`	3 bayt, 6-8 bayt, 10 bayt	`DATETIME2` `DATETIME`'dan daha iyi hassasiyet sağlar	`BirthDate DATE`, `OrderTimestamp DATETIME2`, `EventTime DATETIMEOFFSET`
Binary	`VARBINARY`, `IMAGE`	Değişir	Görüntüler veya belgeler gibi ikili verileri depolamak için	`ProfilePhoto VARBINARY(MAX)`, `DocumentContent VARBINARY(MAX)`
Özel	`UNIQUEIDENTIFIER`, `XML`, `JSON`	16 bayt, değişiklik gösterir, yerel ikili	`UNIQUEIDENTIFIER` GUID'ler için, `XML` XML belgeleri için, `JSON` JSON belgeleri için doğal ikili formatta (SQL 2025+)	`RowGUID UNIQUEIDENTIFIER`, `Config XML`, `Settings JSON`

Veri türlerindeki nüanslara dikkatle yaklaşmak gerekir. Örneğin, finansal veriler için FLOAT kullanmak yerine DECIMAL kullanmak, her bağımlı değeri yeniden hesaplamadan düzeltemeyeceğiniz yuvarlama hatalarına neden olabilir. INT yeterli olduğunda birincil bir UNIQUEIDENTIFIER anahtar, dizin boyutunuzu üçe katlar ve her JOIN işlemi yavaşlatır. Bu kararların çoğu veritabanının performansını etkiler ve sorguların milisaniye veya dakika cinsinden çalıştırılıp çalıştırılmayacağını belirleyebilir.

Tablo boyutu gereksinimlerini tahmin

Tablo boyutu yalnızca depolama maliyetleriyle ilgili değildir; veritabanı işlemlerinizi doğrudan etkiler. Tablo boyutu yedekleme ve geri yükleme sürelerini, dizin yeniden oluşturma sürelerini ve sorgu performansını etkiler.

Önemli

100 bayt yerine satır başına 200 bayt depolayan kötü tasarlanmış bir tablo, depolama gereksinimlerinizi, yedekleme sürelerinizi ve G/Ç gereksinimlerinizi ikiye katlar.

Tablo boyutlandırmayı planlamak için bir diğer senaryo da bulut veritabanları için depolama maliyetlerini hesaplamanız, sınırlı disk alanı tasarlamanız veya arşiv stratejilerini planlamanızdır. Bu senaryoların tümü kaynaklar ve operasyonlar hakkında bilinçli kararlar almak için doğru boyut tahminleri gerektirir.

Örneğin, satır başına fazladan 50 bayt ile günlük 100 milyon işlem depolayan bir perakende şirketi günlük 5 GB israf eder; bu da yıllık 1,8 TB gereksiz depolama alanı ve ayrıca yedekleme süresi ve maliyetlerinde orantılı artıştır.

Aşağıdaki örnek, tablonun boyutunun nasıl tahmin yapılacağını Employee gösterir:

-- Estimate row size for a table
-- Fixed-length columns: sum of column sizes
-- Variable-length: estimate average size
-- Example row calculation:
CREATE TABLE Employee (
    EmployeeID INT,              -- 4 bytes
    FirstName NVARCHAR(50),      -- ~2-100 bytes (avg 40)
    LastName NVARCHAR(50),       -- ~2-100 bytes (avg 40)
    HireDate DATE,               -- 3 bytes
    Salary DECIMAL(10,2)         -- 5 bytes
);  
-- Estimated row size: 4 + 40 + 40 + 3 + 5 = ~92 bytes
-- Plus row overhead (~7 bytes) = ~99 bytes per row
-- 1 million rows ≈ 94 MB

Tip

Tablo boyutu tahminini oluşturmanıza yardımcı olması için Copilot'ı kullanabilirsiniz.

Etkili sütunlar tasarlama

Aşağıdaki örnekte, bu ünitede ele alınan ilkeleri uygulayan iyi tasarlanmış Product bir tablo gösterilmektedir:

CREATE TABLE Product (
    ProductID INT PRIMARY KEY IDENTITY(1,1),       -- Auto-incrementing surrogate key (4 bytes)
    ProductName NVARCHAR(100) NOT NULL,             -- Unicode support, appropriate length, enforced
    Category NVARCHAR(50) NOT NULL,                 -- Smaller than ProductName (categorization needs less space)
    Price DECIMAL(10,2) NOT NULL,                   -- Exact precision for financial data
    StockQuantity INT NOT NULL DEFAULT 0,           -- Integer sufficient for inventory, default prevents nulls
    LastRestocked DATETIME2 DEFAULT GETUTCDATE()    -- Modern date type with automatic timestamp
);

Bu tabloda birkaç en iyi yöntem gösterilmektedir:

Uygun veri türleri: birincil anahtar için (BIGINT veya UNIQUEIDENTIFIER değerlerinden daha küçük), FLOAT yerine, hassas finansal hesaplamalar için DECIMAL(10,2), eskisinden daha iyi duyarlılık için DATETIME2 yerine DATETIME.
Doğru boyutlandırılmış sütunlar: NVARCHAR(100) ürün adları ve NVARCHAR(50) beklenen veri uzunluğuna göre kategoriler için
Kısıtlamalar: NOT NULL Eksik kritik değerleri önleyerek veri kalitesini sağlar
Varsayılan değerler: (0) ve StockQuantity (geçerli UTC saati) için LastRestocked otomatik değerler uygulama kodu karmaşıklığını azaltır
Verimli birincil anahtar: IDENTITY Verimli bir şekilde kümeleyen sıralı anahtarlar oluşturur ve en az depolama alanı kullanır (GUID için 4 bayt ile 16 bayt arası)

Uyarı

Bu örnekte Unicode desteği için (karakter başına 2 bayt) kullanılır NVARCHAR . Verileriniz yalnızca ASCII ise ( VARCHAR karakter başına 1 bayt), dize depolamayı ikiye böler. A ProductName VARCHAR(100) , 30 karakterli bir ad için NVARCHAR(100) ~30 bayt ile ~60 bayt arası kullanır. 10 milyon satırda bu yaklaşık 300 MB tasarruf sağlar. Uluslararası veriler için kullanın NVARCHAR ; depolama verimliliği önemli olduğunda kullanın VARCHAR ve veriler yalnızca ASCII olarak kalır.

En iyi yöntemleri tasarlama

Performans ve bakımdan emin olmak için tabloları tasarlarken ve uygularken şu temel ilkeleri uygulayın:

Uygun veri türlerini kullanma - Daha küçük veri türleri depolamayı azaltır ve performansı artırır
Tablo boyutunu erken düşünün - Depolamayı ve dizin oluşturmayı planlamak için satır boyutunu ve toplam tablo boyutunu tahmin etme
Anlamlı kısıtlamalar uygulama - Veritabanı düzeyinde veri kalitesinden emin olun
Büyümeyi planlama - Gelecekteki veri hacmini işlemek için tablolar tasarlama
Stratejik dizinleme - WHERE, JOIN, ve ORDER BY yan tümcelerinde kullanılan dizin sütunları
Analiz için columnstore seçme - Analitik sorgular içeren büyük tablolar için columnstore dizinlerini kullanma
Uygun olduğunda normalleştirme - Normalleştirmeyi sorgu performansı gereksinimleriyle dengeleme
Satır ve sayfa sıkıştırmayı izleme - Depolamayı kaydetmek için büyük tablolar için sıkıştırmayı etkinleştirme

Veritabanı performansı sorunlarının çoğu, geliştirme aşamasında erken saatlerde alınan kötü tasarım kararlarından kaynak alır. Büyük büyük veri türleri depolamayı ve yavaş sorguları boşa harcar. Eksik veya yanlış dizin türleri, kaynak yükseltmelerinin çözemediği darboğazlar oluşturur. Tabloları oluşturmadan veya değiştirmeden önce uygun nesne tasarımına zaman ayırarak bu sorunları önleyin. Tasarım sırasında aldığınız kararlar (uygun veri türlerini seçme, tablo boyutlarını tahmin etme, doğru dizin türlerini seçme) uzun vadeli performans ve maliyet üzerinde daha sonra uygulayabileceğiniz iyileştirmelerden çok daha fazla etkiye sahiptir.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?