Mustafa Ekim wrote:
>> Ayrıca her veri tabanında farklı olmakla birlikte hazırlamış
> olduğunuz
>> sorguların çalışma planı çıkartılırken de veri tabanı
> sisteminiz bu ilişki
>> tanımlarından yararlanacaktır.
>
> nasil yani? biraz daha acar misiniz?
>
> ornegin ders ogretmen tablolarim var,
> select ogretmen.*, ders.*
> from ders
> inner join ogrenment
> on ders.id=ogretmen.id
>
> sorgusunun calisma hizinin bu 2 tablo arasinda bi iliski tanimlanmis olmasi ve taninlamamis olmasi durumunda farkli mi olacagini soyluyorsunuz?
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.
>
>
>
>> İş kurallarınızı Veri Tabanı sunucusuna değil, uygulama sunucusuna
> çekmelisiniz.
>> Hemen belirteyim burada kastedilen iş kuralları ilişkisel veri
> tabanının
>> bütünlük kuralları değildir. Örneğin derse kayıt olaak
> öğrencinin bir
>> kaydının olmasının kontrolü değil bir derse kayıt olabilecek
> öğreci sayınızın
>> kontrolüdür.
>
> butunluk kurallari bence de cok faydali.
> ve bence de is kurallari uygulama katmaninda olmali.
> peki sizce o halde stored procedure ne ise yarar?
İş kuralları istemci uygulama katmanında olmamalı, sonuçta aslona
veridir, istemci uygulama buna bağlanıp veri gönderip alan bir araçtır
yalnızca ve kurallar istemci uygulamada tanımlanırsa, daha sonra aynı
veri ile çalışacak bir uygulama eklendiğinde aynı kurallar o uygulamada
da tanımlanmak zorunda kalınır, boşuna vakit kaybı. Veri ekleme ve veri
alma kuralları değiştiğinde de bu sefer aynı veriyi kullanan bütün
istemci uygulamaları değiştirmek gerekir, bu daha da tehlikeli bir
durum, uygulamanın birini ikisini yeni duruma göre değiştirdiniz ama
kıyıda köşede kalmış ara sıra kullanılan bir uygulamanın değiştirilmesi
unutulabilir ve bunu kullanıp verilerde değişiklik yapıldığında ayıkla
princin taşını olur sonra.
İş kuralları istemci tarafında olmamalı derken web tabanlı uygulamalarda
da istemci olarak benim gördüğüm web sunucusu oluyor. Kullanıcı
tarafındaki browser yalnızca mainframe devrindeki aptal terminallerin
yaptığının biraz geliştirilmişi, sonuçta uygulamanın kendisi web
sunucusunda çalışıyor ve veriyi arada başka bir uygulama katmanı olmadan
direkt veritabanına bağlanıp alıyorsa o uygulama da klasik iki katmanlı
bir istemci-sunucu uygulamadan çok da farklı değildir. İki katmanlı
uygulamalarda da İş kurallarını tanımlamak için en uygun yer verinin
olduğu yer yani veritabanı sunucusu ve veritabanı sunucu yazılımlarında
bunları yapabilmek için çok güzel özellikler var. Mesela uygulama öyle
şekilde tasarlanır ki istemci uygulamalar, yani web sunucusunda çalışan
web tabanlı uyugulama ve varsa bununla birlikte çalışan diğer istemci
uygulamalar veritabanının tablo yapısını bile bilmek zorunda kalmaz,
herşey stored procedure şeklinde güzelce tanımlanırsa bu istemci
uygulamaları yazmak da kolaylaşır, stok_hareketi_gir diye bir sp
tanımlandığını düşünün, bunu çalıştıran uygulama düzgün parametreleri
yerleştirip çalıştırıp sonucunu kontrol eder o kadar, veriler hangi
tablolara eklenecek, sonrasında başka tablolarda değişiklik olacak mı
bunlar istemcinin işi değil, haliyle bu durumda istemciyi ister bir web
sunucusunda çalıştırın ister masaüstünde çalışan bir visual basic
uygulama yazın hiç farketmez.
>
> ben de MVC haric bi uygulama gelistirmeye karsiyim ve MVC stored procedure mantigina tamamen ters gibi geliyor bana.
>
> ancak bu sefer stored procedure kullanamamin verdigi performans problemi ortaya cikiyor, yaniliyor muyum?
>
> kolay gelsin
Ben de küçük uygulamalar haricinde MVC olayına karşıyım. Stored
Procedurelar içinde select * from tablo1 yazmak için tasarlanmadılar,
bunlar istemciyi tablolardan soyutlamak için yapılmışlar ve o şekilde
kullanıldıklarında aslında işi çok kolaylaştırıyorlar. MVC olayında
veritabanından soyutlanıyorsunuz, bunun tek getirisi yeterince SQL
bilgisi olmayan biri bile uygulama geliştirebilir oluyor ama büyük bir
uygulama yapılacaksa uygulamanın ömrü boyunca bir çok değişiklik görür,
veri ekleyip veri alan farklı istemci uygulamalar eklenir, tonla
revizyon olur, o zaman MVC işi zorlaştırır. MVC ortaya çabucak bir
uygulama çıkarmak için güzel bir araç, mesela bir içerik yönetimi olan
orta karar web sitesi yapmak için birebir ama MVC mantığı ile yazılmış
bir ERP uygulaması uzun vadede işleri zorlaştırır. Veritabanı sistemi
değişirse ne olacak? Uygulamalarda uygulama bir yerde çalışmaya
başlandıktan sonra veritabanı sistemi değiştirmek gibi şeyler pek fazla
olmuyor, baştan bir veritabanına karar verilir, içinde yıllarca veri
birikmiş bir sistemde veritabanını değiştirmek zor bir karar, buna bağlı
çalışan istemci uygulamalar bile bir çok kez değişir ama genellikle
veritabanı aynı kalır, değişmesi için çok geçerli nedenler varsa, biz
oracle kullanmayalım artık posgresql var ve daha güzel daha sağlam
çalışıyor gibi nedenler ortaya çıktığında da artık masrafına ve
zorluğuna katlanılıp stored procedure'lar da artık yeniden yazılıverir.
_______________________________________________
Linux-programlama mailing list
Linux-programlama_at_liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama
Received on Tue 16 Oct 2007 - 13:42:06 EEST