[ssonmez]

Öncelikle söyleyeyim bir yerden okumadım ortada bir şey yok. Ama günlerdir kafamı kurcalıyor.

Olay, bir sitede tree menü sistemi ile navigasyon yaptırmak isterken başladı. Yani bildiğiniz klasör içinde klasör. Bunu veritabanında tutmak istediğimde okulda zamanında hocalarımın anlattıkları zincir liste mantıklarına ve kısmen linkli listeler mantığına girdim.

Böylece bir baktım tüm database modellemelerimiz relational database (ilişkisel veritabanı) modeli dahil olmak üzere 2 boyutlu. Pratik değilller.

Üstte verdiğim örnekte olduğu gibi derinlik dediğimiz 3. boyutları yok. Biliyorum bazı arkadaşlar OLAP yaklaşımından bahsetmek isteyecek. Kısaca, veri analizlerinde, datayı satır ve sutunlardan oluşan bir tablo değil, bir küp olarak ele almak diyelim.

Oysa bu gerçekte 3 boyutlu bir modelleme değil, 2 boyutlu veritabanı tasarımında bir ara çözüm.
Bir dönem nesneye dayalı (object oriented) veritabanı modelleme gündeme geldi ama o kadar.

Verinin fieldlerde tutulduğu, her satırın bir record olduğu klasik model bence eskidi.

Bilginiz ve fikriniz gerçekten güzel bir sohbeti başlatabilir. Uzun zamandır size sormak istediğim bir konu bu.

[soul]

Tree için kullanılan klasik model mantığında ne gibi bir sorun var yani, parentID belirterek sonsuz kategori desteklemekte.

3 boyutlu db nin nasıl bir avanatajı olarabilir yada teknik bir örnek verebilir misin?

OOP tabanlı DB erişimi ORM (Object RElational Mapping) ben projelerimde artık ORM kullanıyorum çok verimli bir ulaşım hatta ORM' den sonra klasik db programcılığı yapınca direk kendimi salak gibi hissediyorum.

Bir de mesela kategori konusunda artık trove kategoriler var, mesela bir ürün sınırsız kategoriye bapımlı olabiliyor. Bu sayede kategori özellikleri de bit kategori olabiliyor. Aynı amazon, slashdot, freshmeat gibi.

[cgencer]

basit bir kural vardır: eskisi işini görüyor ve sorunsuz çalışıyorsa güncellemekten mümkün olduğunca sakın. bu kuralı buna da uygulamak mümkün; 3 boyutlu bir db sadece bir oyuncak olacaktır; sonuçta db normalizasyon / optimizasyon gibi yöntemleri kullanan her veritabanı mimarı bilir ki 2 boyutluda herşey en pratik çözülebilir; en karışık yapılar bile şu anki sistemle kaydedilebilir. rekursiv yapılarla tek tableda bile çok derinlemesine gruplandırmalar vs yapılabilir ve tüm tree tek bir tabloya pratik olarak kaydedilebilir.

soul'un bahsettiği ORM gibi çözümleri ben de merak ettim, buna ve bahsettiğin trove kategorilere örnek ve link verebilirsen güzel olacaktır.

[absconder]

hocam bahsettiğin konu veritabanının işlevini sorgulamak gibi oluyor

ORM konusunda bilgi bekliyorruz ferruh

[ssonmez]

İyi ki sormuşum yeni şeyler öğreniyoruz. Ama üzülerek söyleyeyim ki modeli paylaşamadık.

Rica ederim karışık düşünmeyin. Bir küp düşünün. Bu 3 boyutlu. Biz kağıt üzerine çizdiğimizde resim sanatının öğrettiği gibi iki kare çiziyor ve ayrıtları birleştiriyoruz.

Günümüzde yapılan bu. Bir field iki bağlantı noktasına sahip bir record içinde. (Dikkat record değil field dan bahsediyorum) Önceki field ve sonraki field.

O recordda tablo içnde X-Y diyebileceğimiz bir eksen üzerinde bir kordinata sahip.

Ama farkında olmasakta bize X-Y-Z koordinatlarını içeren bir database lazım. Bunu tam hayal edemiyorum. Sanırım etmeyi başarsam cidden Oracle ya da Microsoft'a satıp köşelik olurum.

Ama beynimde şekillenen yapı şöyle:

Kayıtlardaki değişimler katmanlar halinde saklanır
* Bir kaydın bir alanı değiştiğinde biz bunu loglarda görürürüz. Bu modelde asla kaydın eski hali silinmez. Katmanlar halinde üst üste yerleşir.

* Herhangi bir record her hangi bir record ile sonsuz bağlantı kurabilir.

* Bir fieldin record sayısı tanımsızdır.
Yani isim, soyad, telefon gibi her an yeni field eklenebilir.

* Dördüncü boyuta ait bir veritabanı ise tüm verinin genel görünümünü her record tutar. Mesela holografik kayıt gibi. Asıl filmin küçük bir bölümü bile bütün resmi verir.

* Bir record derinlik boyunca bilgi saklar bu sadece zamansal değildir. Bilginin kademeli manaları ve levellarla bölünmüş security katmanları farklıdır. Mesela admin ve son kullanıcı aynı yorum alanına aynı fielde bakarken farklı görürler. Şu an ise farklılığı yeni field ekleyerek sağlayabiliyoruz. Bu yapıda tüm fieldlar aynı olduğu halde içerik katmanlanmıştır. Photoshoptaki layerlar gibi

Daha düşünüyorum. Ama tahmin edersiniz ki bu yeni database modeli direkt olarak beynin yapısından esinleniyor.

[soul]

OOP' ta genel gizleme mantığını db ye uyarlanması gibi düşünülebilir yani, objenin implemantasyonunu gizliyoruz ve objeyi teknik detaydan soyutlandırıp iş objesini haline sokuyoruz.

Mesela siz Yeni bir üye mi ekleyeceksiniz;
"INSERT INTO Members ..." kullanırsınız. Bu SQL cümleciği kodda anlamsız bir yapıdır. Ek olarak kontrolü zordur.

ORM de bunu mesela şu şekilde kullanırsınız.

Dim YeniUye AS New Member()
YeniUye.Name = "Ahmet"
Members.AddNewMember(YeniUye)

Buradaki güzel olaylardan biri tabii ki yeni üye işleme sırasında random şifre oluşturma vs. gibi prosedürlerin otomatik olarak arkaplanda iobje içerisinde yapılmış olması (tabii ki gene siz yazıyorsunuz ).

Veya kayıt silerken,
Members.DeleteById(1007)

demeniz yeterli.

Esas konu ise programı yazarken SQL' lerle kasmadan program akışını oluşturabilmeniz ve yazabilmeniz.

ORM araçları ise size SQL işlemlerini halledecek kodları ve class ları oluşturmak. DB' nizi veriyor ve biraz ayar yapıyorsunuz daha sonradan size Tüm class' ları oluşturuyor. Bir çoğu birden fazl database destekliyor.

Mesela database SQL server ken istediğiniz zaman Access' a çevirebiliyorsunuz ve tüm özellikler hala çalışıyor, yada MySQL vs. Bu limit tamamen kullandığınız ORM' e bağlı.

Genelde ORM lerde iki parça var biri kodu üreten, classları üreten kısım diğeri ise altyapı kodu. Yani daha önceden yazılmış ana database layer kodu. Bazılarından ön class oluşturma aracı olmuyor manual yapmanız yada XML aracılığı ile ayarları belirtmeniz gerekebiliyor.

ORM ASP gibi bir dilde verimli şekilde kullanamazsınız, JAVA yada .NET dillerinde çok verimli ama. Mesela PHP' de benzer şekilde verim alamamak normaldir. PHP5 in OOP desteği bildiğim kadarıyla güçlü ancak gene de ORM işe yaramayacaktır.

Umarım anlatabilmişimdir, biraz karışık ancak kod örnekleri ve ilgili bir kaç yazılımı inceledeğinizde konuyu çok daha iyi şekilde anlayacaksınız.

Esas kilit programı katmanlara ayırmak, dolayısıyla üst katta iş katmanında kod yazarken SQL gibi alt seviye detaylarla uğraşmamak.

İlginç bir nokta ilgili implemantasyonla database yerine full XML de entegre edilebilir mesela.

Trove kategori sourceforge' un kategori mantığı yani X programı birden fazla kategoride olabilir.

Örnek;
- PHPMyAdmin
Languages > PHP
Database > Management

vs..

Yani burada sadece bir kategoride de değil bir çok kategoride. "Languages > PHP" kategoriside aslında programın özelliği (property). Mesela bu kategorilere şunlar da eklenebilir;

Downloads > Most Downloaded
Alphabetic > P

Bu aslında bloglarda da var basit şekilde "X entry si X,Y,Z klasörlerine kaydedildi" demesi gibi. Yani klasik tek kategori yok.

DB de şu şekilde;

Product
- ID
- Name
...

Category
- ID
- Name
- ParentID


Product_Category
- Product_ID
- Category_ID

Gördüğünüz gibi direk bir ilişki yok arada "Product_Category" tablosu ilişkiyi oluşturuyor.Dolayısıyla sonsuz sayıda sonsuz kategori ilişkisi kurulabiliyor. ParentID ile de gene kategori hiyerarşisi sağlanır.

[ilksen]

uh süper bi bakış açısı. gerçekten o kadar uğraştığım veritabınını hep aslında 2D olarak düşünüyormuşum. ama 3D düşünmek beni aşar galiba... aklım ermez; malum matematiğim zayıftır da...

[soul]

Bugn tesdüfen ORM ile ilgili bir makale karşıma çktı aslında süper bir makale değil ancak yardımcı olacaktır;

Top 10 features for using an O/R mapping tool
http://www.developerland.com/DotNet/Database/415.aspx

[stNonStop]

soul tarafından gönderilen mesaj:

OOP' ta genel gizleme mantığını db ye uyarlanması gibi düşünülebilir yani, objenin implemantasyonunu gizliyoruz ve objeyi teknik detaydan soyutlandırıp iş objesini haline sokuyoruz.

Mesela siz Yeni bir üye mi ekleyeceksiniz;
"INSERT INTO Members ..." kullanırsınız. Bu SQL cümleciği kodda anlamsız bir yapıdır. Ek olarak kontrolü zordur.

ORM de bunu mesela şu şekilde kullanırsınız.

Dim YeniUye AS New Member()
YeniUye.Name = "Ahmet"
Members.AddNewMember(YeniUye)

Buradaki güzel olaylardan biri tabii ki yeni üye işleme sırasında random şifre oluşturma vs. gibi prosedürlerin otomatik olarak arkaplanda iobje içerisinde yapılmış olması (tabii ki gene siz yazıyorsunuz ).

Veya kayıt silerken,
Members.DeleteById(1007)

demeniz yeterli.

Esas konu ise programı yazarken SQL' lerle kasmadan program akışını oluşturabilmeniz ve yazabilmeniz.

ORM araçları ise size SQL işlemlerini halledecek kodları ve class ları oluşturmak. DB' nizi veriyor ve biraz ayar yapıyorsunuz daha sonradan size Tüm class' ları oluşturuyor. Bir çoğu birden fazl database destekliyor.

Mesela database SQL server ken istediğiniz zaman Access' a çevirebiliyorsunuz ve tüm özellikler hala çalışıyor, yada MySQL vs. Bu limit tamamen kullandığınız ORM' e bağlı.

Genelde ORM lerde iki parça var biri kodu üreten, classları üreten kısım diğeri ise altyapı kodu. Yani daha önceden yazılmış ana database layer kodu. Bazılarından ön class oluşturma aracı olmuyor manual yapmanız yada XML aracılığı ile ayarları belirtmeniz gerekebiliyor.

ORM ASP gibi bir dilde verimli şekilde kullanamazsınız, JAVA yada .NET dillerinde çok verimli ama. Mesela PHP' de benzer şekilde verim alamamak normaldir. PHP5 in OOP desteği bildiğim kadarıyla güçlü ancak gene de ORM işe yaramayacaktır.

Umarım anlatabilmişimdir, biraz karışık ancak kod örnekleri ve ilgili bir kaç yazılımı inceledeğinizde konuyu çok daha iyi şekilde anlayacaksınız.

Esas kilit programı katmanlara ayırmak, dolayısıyla üst katta iş katmanında kod yazarken SQL gibi alt seviye detaylarla uğraşmamak.

İlginç bir nokta ilgili implemantasyonla database yerine full XML de entegre edilebilir mesela.

Trove kategori sourceforge' un kategori mantığı yani X programı birden fazla kategoride olabilir.

Örnek;
- PHPMyAdmin
Languages > PHP
Database > Management

vs..

Yani burada sadece bir kategoride de değil bir çok kategoride. "Languages > PHP" kategoriside aslında programın özelliği (property). Mesela bu kategorilere şunlar da eklenebilir;



Bu aslında bloglarda da var basit şekilde "X entry si X,Y,Z klasörlerine kaydedildi" demesi gibi. Yani klasik tek kategori yok.

DB de şu şekilde;

Product
- ID
- Name
...

Category
- ID
- Name
- ParentID


Product_Category
- Product_ID
- Category_ID

Gördüğünüz gibi direk bir ilişki yok arada "Product_Category" tablosu ilişkiyi oluşturuyor.Dolayısıyla sonsuz sayıda sonsuz kategori ilişkisi kurulabiliyor. ParentID ile de gene kategori hiyerarşisi sağlanır.

Elimden geldiği kadarıyla konuyu takip etmeye çalıştım. Sürekli olarak server Client Mimarisinde DB uygulamaları geliştiriyorum. 1. Konu ssonmez hocamın ddiği bir çok şey 2 boyutlu dediğimiz aslında hakikaten bir tabloya benzeyen db mantığında hepsi yapılabilinir. Görünüyor.

Fakat şu açıdan bakılırsa hız kullanım rahatlığı.(Bence birinci kuralını atlıyoruz burada program yazmanın. Basitlik) yapısal değişimler sayesinde kullanımdan ziyade depolama tekniklerinin farklılaşması sonucu bir ilerleme meydana gelebilir.

ORM ise customize yapabiliyorsa ve gerektiğinde normal SQL le sisteme müdahele ederseniz, çok iyi görünüyor. Kodlamayı baya hızlandıracaktır. PHP de kullandığım fonksiyon lib.leri ve C de kullandığım DB kompenentlerine benzemekte.

Not: OOP = Object Oriented Pascal değil miydi. PHP nin veya başka herhangi bir dilin Object Oriented olması onun OOP olduğunumu gösterir. Yoksa OO olduğunu mu ? Bu konuda biraz cahilimde.

[soul]

OOP = Object Oriented Programming ama doğru PHP OOP değil OO