Merhaba,

On Tuesday 16 October 2007 09:53:28 Mustafa Ekim wrote:
> ilişkilerin db'de tanımlanması neye yarar?
>
> integrity constraint'ler sayesinde db'de olmasını istemediğiniz (mantıksal
> açıdan olmasının anlamsız olacağı) durumları engelleyebilirsiniz. örneğin
> bir "ders" acilacaksa, o dersin kesinlikle bir ogretmeni olmali dersek,
> ogretmeni silemeyiz veya ogretmenle dersi birlikte silebiliriz gibi.
>
> bunun disinda ne isimize yarar ben de bilmiyorum. merak da ediyorum.
> cunku zaten iliskiler olsun olmasin bir view yazarken veya bir select,
> insert yazarken bu iliskiler hic tanimlanmamis gibi yeniden anahtarlar
> uzerinden birlestirme yapiyorum.

Temel İlişkisel Bütünlük ( Referential Integrity ) tanımlamalarını veri tabanı
üzerinde yapmalısınız. Bu farklı kaynaklardan gelecek olan verilerin sizin
ilişkisel veri tabanı bütünlüğünüzü bozmasını engelleyecektir.

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.

>
> Halbuki ORM (Object Relational Modeling) kullanirsaniz, (uygulama
> katmaninda, db'de degil) orada iliskileri tanimladiktan sonra ders.ogretmen
> seklinde dersin ogretmenine ulasmak mumkun oluyor.
>

ORM aracı sizin için gerekli SQL sorgularını hazırlar. Eğer veri tabanı
tasarımınızı ve ilişkileri doğru tanımlamadıysanız, ORM arayüzünde daha fazla
performans sorunu ile karşılaşırsınız. ( Burada ORM arçlarına karşı değilim
sadece performans için dikkatli tasarım yapılması gerektiğini söylemeye
çalışıyorum :) )

Ki bu noktada ORM araçları kullanırken temel yaklaşımın veri tabanı tasarımını
nesnelere aktarmak olmamalıdır. Model nesneleriniz arasındaki ilişkileri
tanımlarsınız ardından da ORM aracınızın bunları her hangi bir saklama
ortamında ( illa ilişkisel veri tabanı olmak durumunda değiller, saklama
ortamınız örneğin bir XML neden olmasın ) saklamasını istersiniz.

> ayrica
>
> "veritabanında halledilebilecek herşeyin
> veritabanında halledilmesi ileride istemci uygulamanın
> değiştirilmesini
> kolaylaştırır."
>
> demissiniz, peki veritabaninin degismesi durumunda ne olacak? bence
> veritabani degistirmek ve hatta dagitik bir veritabani gecmek daha olasi.
> dagitik bir veritabanina gecildiginde ne olacak?
>
> ben performansin kilit rol oynamadigi eylemler haric stored procedure
> kullanilmasinin anlamli olacagini da dusunmuyorum. bu tur isler db
> katmaninin uzerinde yapilmali.
>

Bu yöntem İstemci-Sunucu mimarinin temel taşıdır. Genelde istemci sunucu
mimaride iş kurallarınızı veri tabanı sunucusu üzerine taşımak durumunda
kalırsınız. Fakat 3 ( web uygulamaları ) ya da daha çok katmanlı uygulama
geliştiriyorsanız ( ki böyle uygulama geliştirmenizi öneririm :) ) İş
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.

Hem veri tabanından hem de istemci uygulamadan bağımsızlık ya da kolay
değiştirilebilirlik iteniyorsa uymanız gereken en önemli kural MVC (
Modal-View-Control ) desenidir.

> "istemci uygulama" derken neyi kastettiniz?

Sanıyorum istemci-sunucu mimaride kullanılan "istemci uygulama"dır :)

iyi çalışmalar,
Hakan Uygun
_______________________________________________
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 - 09:55:36 EEST