Primary Key: int mi? GUID mi?

Yeni bir ilişkisel veritabanı yaratılırken Primary Key (Birincil Anahtar) türüne karar vermek durumunda kalırız. Genelde ilk veritabanı derslerinde Birincil Anahtarlar int türünde seçildiği için el alışkanlığı olarak int tercih edenler vardır. Peki kuracağımız sisteme göre bu kararı nasıl vermeliyiz?

GUID Nedir?

Açılımı Globally Unique Identifier olan, ve sizin üretmekte olduğunuz birincil anahtarın sadece sizin tablonuzda değil, veritabanınızda değil, tüm sistemler içerisinde tekil olmasını sağlayan bir yapıdır. İki GUID in aynı olma olasılığı yok sayılabilecek kadar düşüktür.

GUID avantajları?

Tabloları veya farklı veritabanlarını birleştirmek istediğinizde GUID'lerin aynı değeri almayacağını bilirsiniz ve bu yüzden veritabanı birleştirmeleri son derece kolay düzenlenebilir.

Örneğin bir Kullanıcı ID'sinin başka hangi tablolarda bulunduğunu araştırmak istediğinizde normalde tabloları elle araştırmak zorundasınız. Hatta çoğu zaman tabloların ilişkilerini de bilmek durumundasınız. Oysa GUID kullandığınızda ve bu GUID değerini bütün tablo alanlarında arayan basit bir Stored Procedure yazdığınızda her GUID değerinin hangi tablolarla ilişkisi olduğunu kısa yoldan ve çok daha kesin olarak görebilirsiniz.

GUID dezavantajları?

GUID test ve geliştirme sürecinde akılda kalıcı bir rakamlar yani int ile çalışmak daha kolay. Örneğin bir tester ya da yazılım geliştirici, kullanıcı ID'sinin 23 olmasını abuk subuk harflerden oluşan bir kelimeye tercih eder.
Bilindiği üzere int 4 byte ile temsil ediliyor. Oysa GUID 16 byte'tan oluşan bir yapı. Dolayısıyla performans ve veri alanı açısından int'e göre daha sorunlu.

Ayrıca GUID içeren bir satırın tabloya eklenmesi, int içeren bir satırın eklenmesinden daha maliyetli. Dolayısıyla yer insertion için ek bir maliyeti de göze almalısınız.

Sonuç?

Sisteminiz küçük kendi halinde şirin bir sistem ise int kullanmaya devam edin. Kendinizi zorlamanın ve tablolarınızı şişirmenin pek de anlamı yok. Lakin eğer sisteminiz büyümeye başladı ve kontrolü zorlaştıysa, dağınık bir mimari içerisindeki çözüm geliştirilmeye çalışılıyorsa, biraz daha performans külfetiyle GUID kullanabilirsiniz.

Referanslar

http://www.sharpdeveloper.net/content/archive/2007/06/25/guid-or-int-primary-key.aspx

http://www.codeproject.com/KB/database/PrimaryKeyINTvsGUID.aspx

Visual Studio 2008 Service Pack 1 ve .NET Framework 3.5 Service Pack 1 çıktı! Bayinizden isteyiniz..

Microsoft özellikle Windows Vista'nın piyasaya sürülmesinin ardından yazılımcılar için çeşitli araçları birer birer geliştirdi. Bunların sonucunda ortaya çıkan yeni ürün gamında Windows Presentation Foundation(WPF), Windows Communication Foundation(WCF), LINQ gibi yeni teknolojilerin yanı sıra Hyper V ve MSSQL 2008 gibi performansa direk etki edebilecek ürünler mevcuttu.

Tabii ki Microsoft ile yıllardır tanışıklığı olan yazılım dünyası, kullanılabilirliği oldukça yüksek olan bu teknolojilerden hemen faydalanmak yerine ölçüp biçmeyi ve "service pack" beklemeyi tercih etti. Şimdi ise muradına eriyor. Özellikle WPF ve ADO.NET yani bir anlamda LINQ için yüzde 20'den 45'e kadar değişen performans artışları bu sefer yazılımcıları ikna edecek gibi.

Ayrıca TFS yani Team Foundation Server üzerinde de çeşitli geliştirmeler yapıldığını da eklemek gerekiyor. Microsoft gerek görsellik ve kullanılabilirlik gerekse performans bakımından rakipleriyle arayı açmak arzusunda. Şimdi bir taraftan son kullanıcı için çok daha kullanışlı ve görsel ürünleri beklerken, bir diğer taraftan da Java ve Özgür Yazılım camiasından Microsoft'un bu atağına cevap bekleyebiliriz.

Ayrıntılı bilgi : (ingilizce)

http://msdn.microsoft.com/en-us/vstudio/products/cc533447.aspx

Linq2SQL ile veritabanı bağlantısı

.Net Framework 3.5 ile yazılımcıların karşısına çıkan LINQ ve bunun en önemli araçlarından biri olan LINQ2SQL çok temel haliyle veri manipülasyonunu kolaylaştırdığı gibi hepimizin pek çok kez üzerinden geçtiği rutinleri daha basit ve kullanıcı dostu hale getiriyor.

IENumerable olarak tanımlanmış bütün koleksiyonlar üzerinde çeşitli sorgular işletmenizi sağlayan LINQ sorgu dili, veritabanı ile entegre çalışma kabiliyetini de LINQ2SQL sayesinde kazanınca pek çok yazılımcı için düşünülmesi gereken bir alternatif oluyor.

Dilerseniz LINQ2SQL aracılığıyla bir veritabanına bağlanmayı ve bu bağlantı üzerinden veri tabanı üzerinde yazma ve okuma işlemleri yapmayı deneyelim.

Veritabanımızda ismi Öğrenci olan ve ÖğrenciNo, AdiSoyadi, DogumTarihi ve Sinif kolonlarını içeren bir tablomuz olsun. Bu tablo içerisindeki sembolik bilgileri ise yukarıdaki gibi hazırlayalım.

Daha sonra bu bilgileri basit bir form üzerinde göstermek için kolları sıvıyoruz.

Öncelikle Form Uygulaması olacak basit bir yeni proje yaratıyoruz. Bu projenin yaratılmasıyla birlikte hemen herkesin tahmin edebileceği üzere aşağıdakine benzer bir ekran ile karşılaşırız.



Şimdi bu form üzerine bir DataGridView ekleyelim ve formu biraz genişletelim.

Verileri göstereceğimiz ekran artık hazır olduğuna göre LINQ2SQL ile ilgili işlemlere geçebiliriz.

İlk olarak veriyi almak istediğimiz tablo veya tablolar için .dbml uzantılı mapping verilerini hazırlamalıyız. Bunun için ilk olarak proje özelliklerinden yeni dosya ekle’yi seçmemiz gerekiyor.



“Add” tuşuna tıklamamız ile birlikte Ogrenci tablosuna karşılık gelecek .dbml uzantılı dosyayı yaratıyoruz. Şimdi bu dmbl dosyası üzerinde yapacağımız değişikliklerle bu dosyayı güncelleyeceğiz.


Server Explorer ekranından istediğimiz veritabanındaki istediğimiz tabloyu buluyor ve bunu dmbl dosyasının üzerine sürükleyip bırakarak tablo özelliklerini LINQ2SQL içerisine kopyalıyoruz.
Geçmişte DataSet yaratarak sağladığımız entegrasyonu artık dbml ile yapıyoruz. Daha sonra kod içerisinde

//Burada ogrenci icin bir data context yaratiliyor.
//istenirse bir connection sinifi ile de yaratilabilir
OgrenciDataContext odc = new OgrenciDataContext();

IEnumerable sonuc = from ogrenciSatir
in odc.Ogrencis
where ogrenciSatir.Sinif == 1
select ogrenciSatir;

dataGridView1.DataSource = sonuc;

şeklindeki kod ile birinci sınıfta okuyan öğrencileri grid’e atabiliyoruz.

Yeni bir öğrenci girmek için ise

//rastgele bilgilerle yeni bir ogrenciyi listemize ekleyelim
Ogrenci yeniOgrenci = new Ogrenci();
yeniOgrenci.OgrenciNo = 5;
yeniOgrenci.AdiSoyadi = "Test ogrenci";
yeniOgrenci.DogumTarihi = DateTime.Now;
yeniOgrenci.Sinif = 1;

//context olusturuluyor
OgrenciDataContext odc = new OgrenciDataContext();
odc.Ogrencis.InsertOnSubmit(yeniOgrenci);

//degisiklikler kaydediliyor.
odc.SubmitChanges();

şeklinde bir kod yeterli.

SubmitChanges komutu veritabanı ile var olan koleksiyonumuzu senkronize ediyor.

Programı çalıştırdığımızda görüntü şu şekilde oluyor:

Tekrarlamakta fayda var ki burada bu örnekte bir Ogrenci objesi ve bunlardan oluşan bir IEnumerable koleksiyonundan faydalandık. DataSet’ler LINQ2SQL için bir anlamda gereksiz hale geldi.

LINQ Performansı ve halen ORACLE ile uyumu olmaması halen soru işaretleri olsa da yeni çözümler için değerlendirilmesi gereken bir alternatif.

Performans?

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1438097&SiteID=1

adresinde yer alan bir araştırmada ortaya çıkan tablo LINQ’in performans açısından rakiplerinden bir hayli geride olduğu yönünde. Sonuçlar:

0.6600693 saniye // Linq to Sql query (bağlantı manuel açılıyor)
0.5737961 saniye // Linq to Sql query (Bağlantı Linq tarafından kontrol ediliyor)
0.1194771 saniye // SqlCommand / SqlDataReader (Bağlantı sürekli olarak açık)
0.1422770 saniye // SqlCommand / SqlDataReader (bağlantı her seferinde açılıp kapatılarak)

Hatırlatmakta fayda var ki LINQ ile sorgu çekerken Cache’den faydalanmadık. Cache kullanıldığı taktirde bu rakamların daha iyi olması beklenir (ki bu hem Hibernate hem de NHibernate için de böyle olmuştur. )

Ayrıca tabii ki LINQ henüz üzerinde çok çalışılacak bir proje. Gelecekte LINQ sadece kullanılabilirlik olarak değil aynı zamanda performans olarak iyi noktalara gelebilir.

SQLite ve XML karşılaştırması...

SQLite nedir?
Yazılımların ve üretilen çözümlerin karmaşıklaşmasının bir sonucu olarak veritabanları yazılımların vazgeçilmez yapıları haline geldi. Başta ORACLE, MsSql gibi veritabanları yazılımların performanslarını optimize edebilmek adına yoğun bir rekabet içerisindeler ve sunucular üzerinde kurulu bu araçlar artık günümüzün olmazsa olmazı.

Lakin özellikle masaüstü uygulamalarda, geliştirilen ürünün bir MsSql gerektirmesi pek de anlamlı değil ve hatta kullanıcı için büyük bir sorun. Teknik mevzularda pek de geçerli bilgisi olmayan bir son kullanıcının sisteminde veritabanı kullanmak adeta intihar. Buna en yaygın çözüm ise XML. Gerek platform bağımsız olması gerekse hem java hem de .net framework tarafından kabullenilmiş ve hatta desteklenen (çeşitli parser fonksiyonları ile) bir standart olması sebebiyle çoğu kez XML tek tercih durumunda.

XML karşısında açık kaynaklı kod felsefesi ile yola çıkan ve bir araç olmaktan öteye geçip tek bir kullanıcı üzerinden en performanslı veritabanı olmak iddiasına kavuşan bir çözüm çoğu zaman göz ardı ediliyor: SQLite

SQLite temel olarak dosya tabanlı olarak çalışıyor. Projenizin içerisine bu kütüphaneyi eklediğinizde kullanıcının belki de haberi bile olmadan bir veritabanı kurabiliyor ve bu veritabanında SQL-92 standardında sorgular çalıştırabiliyorsunuz. 3. versiyonu kullanımda olan bu kütüphane aslen C temelli olmasına rağmen çok sayıda .NET ve JAVA ara sınıfları internet ortamlarında mevcut.

SQLite’ın XML’e üstün olduğu alanlardan bir tanesi de veritabanı formatında olması aslında. Sonuçta bir veritabanı kullanmakta iseniz her zaman aşina olduğunuz bir yapı ve tasarım mevcut. Peki performans açısından bu iki aracın durumları nelerdir?

Test sonuçlarına bakılacak olursa az sayıdaki veri için XML kullanmak son derece mantıklı fakat çok sayıda tekrar eden veriniz olacak ise SQLite performans artırıcı bir etki yaratabilir. Ayrıca yaratılan dosyadaki bilgilerin XML içerisinde son derece okunabilir olması da XML için bir dezavantaj. XML daha kullanıcı dostu ve standart bir yapıda olmasına rağmen SQLite’ın kullanıcıya performans artırıcı tüm özellikleri sunması (indeksleme gibi) da XML için bir dezavantaj. Tabii ki XML’in artık neredeyse temel bir standart olmasından kaynaklanan avantajlarını da göz ardı etmemek gerekir. Zira SQLite için dökümantasyon, yardım dosyaları ve kullanıcı arayüzü gibi konular hala tam olarak standarda ulaşmamış denemelerden ibaret.

Son olarak LINQ to XML de göz ardı edilmemeli. Özellikle .NET Framework 3.5 tabanında kod geliştirenler için her zaman araştırılması gereken bir nokta. Tercih ise yazılım alanındaki her konuda olduğu gibi işe, sürece, platforma, geçmiş tecrübelere bağlı olarak değişir.

Neden LINQ?

Java Hibernate ile piyasaya hızlı bir giriş yaptığı dönemlerde Windows'un NHibernate teknolojisi ile geride kaldığı adeta kabul edilen bir gerçekti. Her ne kadar bazıları veritabanına sorgu yazmanın daha alışılmış kolay ve performanslı bir işlem olduğunu düşünseler de Hibernate kendine önemli bir yer edindi.

Bu günlerde ise Microsoft'un .Net Framework 3.5 'i piyasaya sürmesiyle LINQ kavramı gündemimizde. Aslında Hibernate ile rekabet etmiyor LINQ. Zira sınıfları farklı. Yaratmış olduğunuz bir XML dosyasından, varolan bir dataset'ten, SQL den ve hatta csv dosyalarınızdan sorgu ile obje evet yanlış duymadık obje çekebilmemizi sağlayan altyapıdır LINQ. Performans olarak kıyaslandığında yaptığının bir for each döngüsünden çok daha performanslı olacağını düşünmek şimdilik zor gibi. Fakat hemen her alanda size sorgulama imkanı vermesi bana kalırsa en önemli yanı. Kullanıyor muyum diye soracak olanlar olursa: Evet kullanıyorum.

Öncelikle yazmış olduğumu kod sadeleşiyor. Tutup da bir for each yazarak tüm verilerimi bir datatable üzerinde gezmektense sadece bir sorgu yazıyorum. Verinin hafızada kalıp kalamayacağını seçebiliyorum. Bir sorgu üzerinden geri dönen şeyin obje olması ise bambaşka güzellik. Veriyi çektikten sonra istediğim özelliğini kullanabiliyor ve daha derleme zamanında hata ayıklama yapabiliyorum.

Ayrıca ilerleyen yıllarsa LINQ optimize olabilecek ve performansı artacaktır diye tahmin ediyorum. Bu durumda yazdığım kodu da tekrar geri dönerek değiştirmek gerekmeyecek.

Eksilerini ancak eskilerin artıları olarak sıralayabiliriz. bir sorgu sırasında değeri bulunca break komutu koymak pek de mümkün değil ve tüm koleksiyonu gezmeniz gerekiyor mecburen. Bu da performansa olumsuz yansıyor.

Kimbilir belki de düşüncelerim yeni olana yalakalıktan ibarettir. Bunu ancak zaman gösterir.

WPF ne ola ki?

Mesleğin en sıkıntılı yanlarından bir tanesi de sürekli değişime açık olma zorunluluğudur. Bu özellik hepimizin cv'lerinde yer ede dursun buna ayak uydurmak da kolay değil. .NET Framework 3.5 ile birlikte tanıştığımız ve Microsoft tarafından geçtiğimiz dönemlerde tanıtılan Windows Presentation Foundation da alışkanlıklarımızı değiştireceğe benzer.

Peki ne ola ki bu WPF dedikleri? Efenim kısaca açıklamak gerekirse Microsoft tarafından hem Macromedia Flash benzeri grafik kabiliyetlere sahip hem de halen kullanılmakta olan Windows Forms yapısını geliştiren altyapıdır. Gerek web tabanlı gerekse masaüstü uygulamalarda çok benzer yapılarla kullanabilecek bu altyapı yakın zamanda düğmelerin uçup kaçmasına sebebiyet verebilecektir. Bu görsel iddiasından dolayı WPF aslen sadece yazılımcılar için değil aynı zamanda grafik tasarımcıları için de önem arz ediyor. Zira Microsoft aslında grafik tasarım ve kodlama kavramlarını WPF sayesinde ayırdı bile. Bir taraftan Microsoft Blend ile tasarımcılar cafcaflı arayüzleri tasarlarken diğer taraftan da yazılımcılar Visual Studio ile kodlarını bu görsele bağımlı kalarak geliştirmek durumundalar.

Ayrıca Windows Forms tarafında tanımlı olan kontrollerin de neredeyse baştan aşağı değiştiğini, gözden geçirildiğini ve ilk kez kullanan bir yazılımcı da afallama hissi yarattığını da not etmek isterim. Olumlu ve olumsuz yönlerini görmezden gelerek kullanmaya şartlandığımız Windows Form'larında adeta reform ve hatta rönesans devri yaşanıyor.

Her ne kadar WPF emekleme dönemindeki bir bebek olsa da orta ve uzun vadede bu konuda çok konuşulacağı aşikar. Fakat Microsoft uzmanlarının bizat verdikleri tavsiyelere dayanılarak söylüyorum ki tamamen WPF ile yapılacak bir yazılım için henüz çok erken. Windows Forms ve WPF karışımı bir yaklaşım bu aralar daha temkinli. Bekleyelim görelim.. Bahisler açıldı..