From: DoganZorlu (doganzorlu@doganzorlu.com)
Date: Wed 28 Jan 2004 - 05:48:19 EST
FA> Merhabalar,
FA> Database olarak Oracle kullaniyoruz. Fakat gordugum kadariyla Orcale Ref.
FA> Integrity icin sadece "on delete" yapisini destekliyor. Yani ancak parent
FA> tablodan bir veri silinince child tabloda ne yapilacagini bu sekilde
FA> belirtiyorsunuz.
FA> Ama "on update" gibi bir ozelligi yok. Tabi bu soylediklerim constraint
FA> tanimlanirken verilen ozellikler.
FA> Oysa okudugum bir dokumanda ref. İntegrity icin bu kisitli yapiyi degil de
FA> triggerlari kullanmayi oneriyor. Ayni zamanda update ve daha fazlasi icinde
FA> kontrol koymak mumkun oluyormus.
FA> Benim sormak istedigim....
FA> Siz ref. İntegrity icin trigger mi yoksa constraint'lerimi tavsiye
FA> edersiniz?
FA> tsk
Karmaşık veritabanlarında, RI sadece kayıtların varlığı
yokluğuyla ilgili bir kavram değildir. Genellikle bir tablodan silme
işleminde, bağlı tablolardan kayıtların silinmesinden öte diğer bazı
tablolarda da güncelleme yapılması gerekir. Bu güncelleme de
çoğunlukla n adet artır veya azalt şeklinde değildir. Örneğin dövizli bir kaydın
silinmesi durumunda, master tablodan ilgili dövizin TL karşılığının
düşürülmesi yada 1 bidon stok kaydı silindiğinde stok kaydından
50 litre düşürülmesi gibi. Eğer aradaki bağlantı çok basitse, yani sadece bu
silindiğinde bağlı kayıtları da sil gibi, trigger kullanmayabilirsiniz
belki. Ama çoğu durumda işlem bundan daha karmaşıktır. BL ve RI
kavramlarının birbirinden ayrılması önemlidir. Ama çoğunlukla ikisi
içiçe geçmiştir. Bu nedenle yapılacak iyi bir çalışmayla trigger lar
aracılığıyla yapılabilecek tüm işlemleri dababase e gömmek oldukça
önemlidir. Bunu yapabilmek için de trigger yazarken kullanılan dil
önemlidir. Trigger lar içine normal uygulama içine yazdığınız gibi kod
yazabilirsiniz. Bu sayede, db yi kullanan uygulama (3rd party bir
uygulama kendi uygulamanız vs) database üzerinde bir değişiklik
yaptığında, db server stabiliteyi kendisi sağlayabilir. Bu ise
hazırladığınız sistemin her durumda güvenli olmasını sağlar.
Uygulamanın kendisine, RI la ilgili hiçbir kod koymak gerekmeyecek
şekilde hazırlanan bir db, kendi başına her türlü bağlantı durumunda
stabil kalabilir. Peki performans ? Zaten trigger yazmanızı
gerektirecek bir bağıntı sözkonusuysa, bunu trigger la yapmasanız bile
uygulamaya gömmek zorunda kalacağınız muhakkaktır. Trigger
yazmadığınız durumda elde edeceğniz performans, uygulama ve database
arasında daha fazla trafik oluşmasıyla daha fazla bir performans
düşüklüğüyle yine karşınıza çıkacaktır.
Maalesef en büyük yazılım firmalarının bile, değişik db leri aynı anda
destekleme kaygısıyla tüm RI işlemlerini uygulamalarının içine
koyduklarını görüyoruz. biraz biraz batch işlemler için SP görürsünüz
o kadar. Bu nedenle özellikle 3. parti bir şey yazacağınız zaman her
halükarda onların vereceği komponentlere ihtiyaç duyuyorsunuz. Verilen
componentler ise genelde RI fonksiyonlarını barındırıyorlar. İyi bir
database dizaynı, değişiklik isteği nerden gelirse gelsin RI ı
muhafaza edebilen ve stabiliteyi kaybetmeyen dizayndır bana göre.
Ama bu söylediğim, development sürecini uzatan bir işlemdir. Bana göre
buna harcanan zamana kesinlikle değer.
-- Dogan Zorlu Grup Software, Izmir