>Eğer uygulamada istemci tarafında select * gibi bir sorgu varsa, yani
 
>sorgulanacak alanlar isimleriyle belirtilmemişse bu en basit
 anlamında
>veritabanı sunucusuna işkence etmek olur. Veritabanı küçükse
 sorun değil
>ama verilerin biraz büyüyeceği bir sistemde bundan kaçının.

>Her veri tabanı sunucusu sorguyu çalıştırmadan önce yazmış
 olduğunuz SQL
>cümlesini parçalayıp en hızlı nasıl çalıştıracağının
 planını çıkartır. Bu
>planın çıkartılması sırasında tanımlanan ilişkiler sunucunun
 ön önemli
>yardımcılarından biridir. Tabii ki her veri tabanı sunucusunun
 yoğurt yiyişi
>farklıdır :) dolayısı ile kiminde daha büyük önem taşırken
 kiminde daha az
>önem taşıyor olabilir.

bu iki bilgi için de teşekkür. hiç duymamıştım.

iş kurallarının nerde olması gerektiği konusunda, benim genelde okuduğum kaynaklar veritabanında olmaması gerektiğini söylemişti.
Ancak sizin yaptığınız açıklama da yerinde.

Ancak şunları da söylemek gerekir:

Veritabanı size programlama için yeterli esnekliği vermiyor. Bir ruby dili ile atacağınız taklaları SQL veya stored procedure'lerle atamazsınız. Bu bağlamda iş kurallarının uygulamada yazılması daha kesin ve kolay bir sonuç vermez mi?

sistemin büyümesi durumunda, bütün sistemin Stored Procedure'ler üzerine yazılmış olması bir de stored procedure karmaşası yaratıyor. Şuan bizim 3 aydır yazmakta olduğumuz sistem bile 100 SP'ye vardı. Mutlaka bu SP'leri de organize etmenin kolay yönleri vardır ancak hiç bir zaman bir ruby'deki oo yapısına kavuşamayacağımız aşikar.

Ve daha önce belirttiğim Dağıtık Veritabanı Sistemleri kurulduğu vakit SP'leri ne yapacağımız konusu var. Biz şuan 1 merkezi, 2 de lokal veritabanı kullanıyoruz. iş kurallarını veritabanı katmanında SP'Lerde tuttuğumuz için 3ünde ortak bir SP değişikliği bizi zorluyor.

Ve artık bir veritabanı katmanı ve birden çok uygulama katmanlı yapılara ihtiyaç duyuluyor. örneğin aynı sisteme cep telefonu ile (wap), bilgisayar ile veya cepten bir mesaj ile veri girmek ve almak mümkün olabiliyor. bu durumda hepsi için farklı sp'ler yazılması gene her şeyi ortak bir havuzda topladığı için karmaşa yaratıyor kanımca. halbuki bir uygulama katmanında OO yapısıyla daha kolay çözümler bulunabilirdi.

Tabiki uygulama katmanında tanımlanan iş kuralları performansda problem yaşatabiliyor. Ancak bu konuda genelde cevap aynı: "Hardware is cheap"

aynı şekilde MVC modelinin de tek handikapı performans. Onun dışında uygulama ne kadar büyük olursa MVC sizi o kadar kurtarırmış gibi geliyor. Ancak hangi ilkeyi savunuyorsam hayat bana diğer ilkelerle iş yaptırıyor. MVC'de de durum aynı. Büyük bir uygulama yazıp deneme şansım olmadı. Bir dahaki projem için kesin MVC deneyeceğiz, tecrübelerimi paylaşırım.

Kolay gelsin.

Mustafa Ekim

      ____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

_______________________________________________
Linux-programlama mailing list
Linux-programlama_at_liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama
Received on Wed 17 Oct 2007 - 09:19:55 EEST