C# tarafında rastgele sayıya ihtiyacımız olduğunda Random class’ından yeni bir nesne üretip kullanabiliyoruz. Eğer rastgele sayıya Sql tarafında ihtiyacımız olursa yapmamız gereken, RAND() fonksiyonunu kullanmaktır.

RAND() fonksiyonu ile ilgili detaylı bilgiye MSDN‘de yeralan şu makaleden ulaşabilirsiniz.

RAND([seed]) fonksiyonu parametre olarak seed değeri alabilir ve geriye float tipinde sonuç döner.

seed parametresi int, smallint veya tinyint tipinde olabilir.

RAND() fonksiyonu aynı seed değeri ile her çalıştırıldığında aynı “rastgele” sayıyı döndürür. Eğer seed verilmezse, Sql Server rastgele bir seed değeri atayarak, “rastgele” sayı oluşturur.

Eğer RAND() fonksiyonundan float tipinde noktalı sayı değil, int tipinde tamsayı dönmesini istiyorsak, basit bir convert işlemine tabi tutabiliriz;

SELECT CONVERT(INT, RAND() * 100)

Bu yazımda, bilgisayarda kurulu programları, LINQ kullanarak nasıl sorgulayacağımızı inceleyeceğim.

Bilgisayara kurduğumuz her program bilgisayarın Registry‘sine kurulum ile ilgili bir kayıt bırakır.

Bilmeyenler için not: Registry’yi açmak için komut satırına regedit yazmanız yeterli.

Registry ile ilgili daha detaylı bilgi için MSDN: Registry sayfasına bakmanızı tavsiye ederim.

Registry‘nin LocalMachine\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall dalında, bilgisayara kurulu olan uygulamalara ve bu uygulamalar ile ilgili bilgilere ulaşılabilir.

Uygulamamızda, Registry class’ını kullanabilmek için, kodumuza aşağıdaki namespace’i eklememiz gerekiyor.

using Microsoft.Win32;

Hemen form tasarlamakla başlayalım.

Yukarıdaki formu oluşturduktan sonra btnGetir butonunun Click olayına aşağıdaki kodu yazalım;

using (RegistryKey rk = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall"))
{
	var programlar = from k in rk.GetSubKeyNames()
					 let r = rk.OpenSubKey(k)
					 select r.GetValue("DisplayName");

	foreach (string program in programlar)
		if (!string.IsNullOrWhiteSpace(program))
			lbProgramlar.Items.Add(program);
}

Registry sınıfının static LocalMachine üyesi üzerinden OpenSubKey() method’unu çağırıyoruz.

Daha sonra yaptığımız;

from k in rk.GetSubKeyNames()
let r = rk.OpenSubKey(k)
select r.GetValue("DisplayName");

LINQ sorgusunu yazmak oluyor. Bu sorgu, ilgili Registry dalının altında bulunan tüm dalları açar ve içlerindeki DisplayName anahtarının değerini getirir.

Son olarak basit bir foreach döngüsü ile bu değerleri lbProgramlar Listbox kontrolüne dolduruyoruz.

İşte benim bilgisayarımdaki sonuç;

Bilgisayar Programcılığı dünyasında genellikle bir işi yapmanın birden fazla yolu vardır. Özellikle veritabanı tarafında bu yollar daha da fazla olabilir. Uygulama Geliştiriciler olarak yeni bir kod parçası yazacağımız zaman, genellikle bu yollardan en çok kullandığımız bir tanesini seçeriz ve onu kullanırız.

Ne var ki, seçtiğimiz yol herzaman en doğru yol olmayabilir. Sql‘de join‘li sorgulama yaparken, filtreleme için kullandığımız yöntem de bunlardan biri olabilir.

Bu yazımda join‘li sorgularda filtreleme için seçebileceğimiz iki yolu karşılaştıracağım. Karşılaştırma yapmak için kendi bilgisayarımda kurulu olan Sql Server 2008 üzerinde AdventureWorkd2008 R2 veritabanını kullandım.

Eğer birden fazla tablonun join‘ler ile ilişkilendirildiği bir sorgu yazıyorsak, sonuç kümesini filtreleme için kullanabileceğimiz iki yöntem vardır;

WHERE Filtreleme

Sonuç kümesinde olmasını/olmamasını istediğimiz kayıtları sorgunun WHERE cümlesinde tanımlarız. Şablon;

SELECT
	[TABLE1.ALANADLARI],
	[TABLE2.ALANADLARI]
FROM
	[TABLE1]
	JOIN [TABLE2] ON [TABLE1.ALAN1] = [TABLE2.ALAN1]
WHERE
	[TABLE1.ALAN2] = DEGER AND
	[TABLE2.ALAN2] = DEGER

JOIN Filtreleme

Sonuç kümesinde olmasını/olmamasını istediğimiz kayıtları sorgunun JOIN cümlelerinde tanımlarız. Şablon;

SELECT
	[TABLE1.ALANADLARI],
	[TABLE2.ALANADLARI]
FROM
	[TABLE1]
	JOIN [TABLE2] ON [TABLE1.ALAN1] = [TABLE2.ALAN1] AND [TABLE1.ALAN2] = DEGER AND [TABLE2.ALAN2] = DEGER

AdventureWorks2008 R2 veritabanında aşağıdaki iki sorguyu çalıştırdıktan sonra, performans analizini yapalım;

WHERE Filtreleme

SELECT
	*
FROM
	Sales.SalesOrderHeader AS SOH WITH (NOLOCK)
	JOIN Sales.SalesOrderDetail AS SOD WITH (NOLOCK) ON SOH.SalesOrderID = SOD.SalesOrderID
	JOIN Sales.SalesOrderHeaderSalesReason AS SOHSR WITH (NOLOCK) ON SOHSR.SalesOrderID = SOH.SalesOrderID
	JOIN Sales.SalesReason AS SR WITH (NOLOCK) ON SOHSR.SalesReasonID = SR.SalesReasonID
WHERE
	SOH.CustomerID > 15000 AND
	SOD.LineTotal > 2000 AND
	SR.SalesReasonID > 5

JOIN Filtreleme

SELECT
	*
FROM
	Sales.SalesOrderHeader AS SOH WITH (NOLOCK)
	JOIN Sales.SalesOrderDetail AS SOD WITH (NOLOCK) ON SOH.SalesOrderID = SOD.SalesOrderID AND SOH.CustomerID > 15000 AND SOD.LineTotal > 2000
	JOIN Sales.SalesOrderHeaderSalesReason AS SOHSR WITH (NOLOCK) ON SOHSR.SalesOrderID = SOH.SalesOrderID
	JOIN Sales.SalesReason AS SR WITH (NOLOCK) ON SOHSR.SalesReasonID = SR.SalesReasonID AND SR.SalesReasonID > 5

Her iki sorgu da çalıştıktan sonra 1321 satır geri döndürdü. Performans incelemesini üç alanda yapacağız;

• CPU Kullanımı
• Disk Kullanımı
• Hafıza Kullanımı

Bu üç performans kriteri için verileri  SYS.SYSPROCESSES DMV‘sinden alabiliriz. SYS.SYSPROCESSES için detaylı bilgiye MSDN‘deki şu makaleden ulaşabilirsiniz. Aşağıda ilgili üç performans kriteri için verileri elde edebileceğimiz sorgu var;

SELECT
	DB_NAME(SP.DBID) AS VERITABANI,
	EST.TEXT AS SORGU,
	CPU,
	PHYSICAL_IO AS DISK_OKUMA,
	MEMUSAGE AS HAFIZA_KULLANIM
FROM
	SYS.SYSPROCESSES AS SP
	CROSS APPLY SYS.DM_EXEC_SQL_TEXT(SP.SQL_HANDLE) AS EST

Bu sorguyu çalıştırdıktan sonra benim test bilgisayarımda şu verileri elde ettim;

• VERITABANI : AdventureWorks2008R2
• CPU : 1965
• DISK_OKUMA : 211
• HAFIZA_KULLANIM : 2

• VERITABANI : AdventureWorks2008R2
• CPU : 156
• DISK_OKUMA : 0
• HAFIZA_KULLANIM : 2

Gördüğünüz gibi kaynak kullanımı açısından (özellikle Disk Okuma ve CPU Kullanımı açısından) JOIN Filtreleme, WHERE Filtrelemeden daha avantajlı.

JOIN Filtreleme tabloları eşlerken filtrelenmiş verileri kullanıyor, WHERE Filtreleme ise, önce tabloları eşleştiriyor sonra filtreliyor. Özellikle çok kayıt bulunan/bulunacak olan tablolarınıza sorgu yazarken, JOIN Filtreleme’yi kullanmanızı tavsiye ederim.

Uygulamalarımızda verileri hash‘lemeye her zaman ihtiyaç duyarız. Verileri hash’lemek için kullanabileceğimiz birçok araç vardır.

Eğer veriyi veritabanı katmanında (Sql Server) hash’lemek istiyorsak, MSDN‘de şu sayfada bulunan makalede okuyabileceğiniz gibi HASHBYTES fonksiyonu ile  yapabiliriz.

HASHBYTES fonksiyonu iki parametre alır;

Algoritma: Hash’leme algoritması. Alabileceği değerler; MD2, MD4, MD5, SHA, SHA1

Veri: Hash işlemine tabi tutulacak veri

HASHBYTES fonksiyonu geriye VarBinary(8000) tipinde değer döndürür.

MD5 algoritması ile hash işlemi yapan örnek kod;

SELECT
	KULLANICI_KODU,
	KULLANICI_ADI,
	HASHBYTES('MD5', KULLANICI_SIFRE) AS KULLANICI_SIFRE
FROM
	T_KULLANICI WITH (NOLOCK)

CREATE PROCEDURE PR_KULLANICI_EKLE
(
	@KULLANICI_KODU VARCHAR(5),
	@KULLANICI_ADI VARCHAR(50),
	@KULLANICI_SIFRE VARCHAR(15)
)
AS
INSERT INTO T_KULLANICI
	(KULLANICI_KODU, KULLANICI_ADI, KULLANICI_SIFRE, KAYIT_TARIHI)
VALUES
	(@KULLANICI_KODU, @KULLANICI_ADI, HASHBYTES('MD5', @KULLANICI_SIFRE), GETDATE())

SELECT SCOPE_IDENTITY()

CREATE PROCEDURE PR_KULLANICI_LOGIN
(
	@KULLANICI_ADI VARCHAR(50),
	@KULLANICI_SIFRE VARCHAR(15)
)
AS
SELECT
	KULLANICI_KODU,
	KULLANICI_ADI,
	HASHBYTES('MD5', KULLANICI_SIFRE) AS KULLANICI_SIFRE
FROM
	T_KULLANICI WITH (NOLOCK)
WHERE
	KULLANICI_ADI = @KULLANICI_ADI AND
	KULLANICI_SIFRE = HASHBYTES('MD5', @KULLANICI_SIFRE)

Güvenlik ihtiyaçlarından ötürü kıymetli bilgilerin network’ten ulaşılmasını önlemek için, veriyi taşımadan önce hash‘lemek isteyebilirsiniz. HASHBYTES fonksiyonu bu işin son derece kullanışlı gözüküyor.

Not : Yazıyı yazdıktan sonra gördüm ki, Emre Ayrılmaz şuradaki makalesinde aynı konuyu işlemiş, okunmasında fayda var.