composite primary key

[selsoft]

sql composite primary key (birleşik anahtar) neden kullanilir, kullanmanin ne gibi avantajları vardır?

[omurolmez]

Genel mantık, gereken tüm veri alanlarını tamamladıktan sonra fazladan bir tane integer not null autoinc alan tanımlamak ve bu alanı primary key yapmaktır.

Bu mantığın dışına çıkmalıyız :

Kişileri tuttuğumuz Ad, Soyad, BabaAdi ve TcNo alanları bulunan bir tablomuz olsun :

create table Kisiler (
Ad varchar(20),
Soyad varchar(20),
BabaAdi varchar(20),
TcNo varchar(11)
);

Şimdi bu tabloyu, veri bütünlüğü açısından değiştirelim :

create table Kisiler (
Ad varchar(20) not null,
Soyad varchar(20) not null,
BabaAdi varchar(20) not null,
TcNo varchar(11) not null,

constraint PK_Kisiler primary key (TcNo, Ad, Soyad, BabaAdi),
constraint UQ_Kisiler1 unique (TcNo),
constraint UQ_Kisiler1 unique (Ad, Soyad, BabaAdi)
);

İşte buradaki gibi key birden fazla alandan oluşuyor ise, composite key adı veriliyor. Ayrıca, zaten unique key içinde geçen bir alan içerdiği için compund key tanımına da giriyor sanırım.

Bu örnekte neden buna ihtiyaç duyuyoruz ? Tek tek tüm alanlar tekrar edebilir, hatta (Ad, Soyad), (Ad, BabaAdi) veya (Soyad, BabaAdi) grupları da tekrar edebilir. Ancak (Ad, Soyad, Baba Adi) grubu tekrar edemez. TcNo tekrar edemez.

Buna alternatif aşağıdaki yapı olabilir. Bu durumda key compound değildir ama composite dir. Aşağıdaki yapı ile yukarıdaki yapı arasındaki fark doğal sıralama (natural order) dır. Yani insert işlemlerinde veya order by kullanılmayan select işlemlerinde göreceğimiz sıralama. Aşağıdaki tablo, Ad, Soyad, BabaAdi fiziksel sıralamasını üretir. Önceki örnek ise TcNo fiziksel sıralamasını üretir. Ancak her iki örnek de her iki sıralamaya ait indeksi içerir (unique keylerden dolayı) ve order by sorgularınaa performanslı cevap verir.

create table Kisiler (
Ad varchar(20) not null,
Soyad varchar(20) not null,
BabaAdi varchar(20) not null,
TcNo varchar(11) not null,

constraint PK_Kisiler primary key (Ad, Soyad, BabaAdi),
constraint UQ_Kisiler1 unique (TcNo),
);

[selsoft]

Hız anlamında hiç bir faydasını göremedim.

[mrmarman]

Hızı nasıl gözlemliyorsunuz. SQLManager ile sorgu sonucunu analiz eden kısımdan bakıyorsunuz değil mi? Yoksa execute edince gelen cevabı gözle mi kontrol ediyorsunuz?

Bunu şunun için sordum ; sorgu hızı;
- Ağ trafiği ve/veya sql kurgusu (dönen değer alan sayısı, iç içe select kurmak, çok fazla calculated alan) ,
- Ağ alt yapısı (wifi/lan/3g),
- Sorgunun index yapısına aksi yönde olması.
- ....
gibi parametrik sebeplerin de gözetilmesi gerekir.

SQLManager ile sayısal olarak karşılaştırabiliyor olmanız çok önemli. Böylece indexlerin yeniden deneme/yanılma ile yapılandırıp sorgu hızı konusundaki problemi bulabilirsiniz.

Yoksa index kurarsınız sql select satırları süper hızlanır ama çok fazla alan eklemişsinizdir insert satırlarınız kağnı hızına düşer. Bunun gibi çapraz sorgu ve giriş testleri yapmakla yükümlüsünüz.

En doğrusu, projenizdeki sorguları baz alıp, onlara özgü yapılanmaya gitmelisiniz.

Başarılar.

[selsoft]

Test tablolarımın create kodunu yazayım.

birinci tablom şu:

USE [deneme]
GO


SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[kisiOnePrimary](
[id] [int] IDENTITY(1,1) NOT NULL,
[tckimlik] [bigint] NOT NULL,
[ad] [nvarchar](50) NOT NULL,
[soyad] [nvarchar](50) NOT NULL,
[dtarih] [date] NOT NULL,
[dyeri] [nvarchar](50) NULL,
[anaad] [nvarchar](50) NOT NULL,
[babaad] [nvarchar](50) NOT NULL,
[ikametgahadres] [nvarchar](300) NULL,
PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO



ikinci tablom şu:

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[kisiCompositePrimary](
[id] [int] IDENTITY(1,1) NOT NULL,
[tckimlik] [bigint] NOT NULL,
[ad] [nvarchar](50) NOT NULL,
[soyad] [nvarchar](50) NOT NULL,
[dtarih] [date] NOT NULL,
[dyeri] [nvarchar](50) NULL,
[anaad] [nvarchar](50) NOT NULL,
[babaad] [nvarchar](50) NOT NULL,
[ikametgahadres] [nvarchar](300) NULL,
PRIMARY KEY CLUSTERED
(
[id] ASC,
[tckimlik] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO


ikisinin içinde de 1.500.000 data var. datalar aynı.

zamanıda şöyle ölçüyorum:

set statistics time on
select * from dbo.kisiOnePrimary
set statistics time off

lokal de çalışıyorum.

[mrmarman]

Mesajımı anlamamış olduğun açık olarak görünüyor.

(*) Sürekli select * from deyip mi kullanıyorsun projendeki sorgularda ? Öyle ise neden ?

(*) SELECT * FROM dediğinde gelen verinin senin indexlerinle doğrudan ilgisi yoktur. Hız farkı görememen doğaldır.

(*) Bu tarz sorgundaki hız anlamında etkileyen nedir biliyor musun; fiziksel network trafiğinin yapısından başlar (hani 3G / WiFi vs. derken WiFi ise WEP oluşu veya WSA oluşu bile fark eder çünkü her şifreleme zaman alır), raporlamada kullandığın bileşenin (DBGrid veya üçüncü parti görsel özellik barındırırken arka planda gruplama vs. yapan ve bundan dolayı yavaşlık oluşabilen) veya tekniğin ne olduğuna kadar olan akış, yani bilginin görsele dönüştüğü zincir belirler.

(*) WEB üzerinden raporlama yapıyorsan 1,5 milyon kayıtla oluşan HTML dosyanın hesabını hiç yapmam bile.

(*) Hiç JOIN kullanmıyor musun, hiç calculated ( SUM, CAST vs. ) kullamıyor musun, hiç iç içe select kullanmıyor musun ?

ÖZETLE : INDEX alanların performansını aslen onlarda deneyebilirsin. Zaman aralığı, değer aralığı vererek filtrelediğin kayıtlarda gözlemlersin.