9 Ekim 2016 Pazar

Schema-On-Write Schema-On-Read Kıyaslaması

İki yeni terim ile karşılaştım, yeni karşılaşmış olman bunların yeni türetildiği anlamına gelmiyor, ne zaman türetildiklerini bilmiyorum fakat bundan sonra daha çok karşılaşacağımızdan eminim. Bu nedenle  terimleri açıklamak ve kıyaslamak istedim, başucu kaynağı olarak dursun.

Schema-On-Write


SQL developer ve adminlerin veri tabanı ya da tablo dendiğinde zihinlerinde ilk canlandırdıkları olgudur. Biraz daha açarsak, önce bir çerçeve tanımlayıp şemanızı belirliyorsunuz, ardından verilerinizi yazıyor ve okuyorsunuz. E bunda ne var, bunu zaten biliyorduk. Aynen öyle. Peki schema-on-read ne?

Schema-On-Read


Bunda ise schema-on-write'da olandan farklı bir süreç işletiyorsunuz. Şemanızı tanımlamak yerine verilerinizi olduğu gibi yüklüyorsunuz. Sıra okumaya geldiğinde ise elinize merceğinizi alıyor ve ya gözlüğünüzü takıyorsunuz. Gözlük veya mercek diyorum çünkü veriyi olduğu gibi yüklediğinizden dolayı detaylara inebilmek için merceğe, uzaktan, yakından ya da  farklı açılardan farklı boyutlardan bakabilmek için gözlüğe ihtiyacınız oluyor. 3D gözlükleri düşünün.

Örnek ile somutlaştırmaya çalışalım. Elinizde bir anket formu var ve bunu veri tabına kaydetmek istiyorsunuz. Schema-on-write, tablo veya tablolar tasarlayıp verileri bunların içini yazarsanız, diğerinde ise formu olduğu gibi sisteme yüklersiniz. Örneğin JSON veya XML.  Peki niye buna ihtiyaç duyalım ki?

Neden Schema-On-Read


Yukarıdaki örneğimizi düşünelim; ankete yeni bir soru eklendi veya çıkartıldı, cevap seçenekleri değişti. Gidip şemanızı değiştirmek ve yeni yapıya uyarlamak zorunda kalırsınız. Oysaki ikinci seçenekte buna ihtiyaç olmaz. Fakat asıl sebep bu değil, gerçek fayda okuma yaparken ortaya çıkıyor. Terimin isminde "Read" geçiyor olmasının nedeni de bu olsa gerek.

Verilerimiz varlıklarımızdır ve varlıkları kullanan kişiler, kişilerin rolleri birbirlerinden çok farklıdır. Varlıklardan değer üretebilmek için kendi çerçevelerinden bakmaya ihtiyaç duyuyorlar. Biz bir şemaya oturttuğumuz zaman, kullanıcılar çerçeveleri ile uyuşmayabilir. Bazılarının çerçeveleri 10x15, bazılarının 15x20 bazılarının ki ise 20x30 boyutlarındadır.  Biz 15x20 seçtiğimizde diğerlerininkine uymayacaktır.

Uydurmak için tekrar tasarım , geliştirme ve devreye alma durumunda kalınır ki, bu da ekstra maliyet ve zaman demektir. Hepsine uyabilmesi için en büyük çerçeveyi seçtiğimizde ise fazladan yer tutmanın maliyeti gelir. Hepsi için ayrı ayrı çerçeveler oluştursanız, maliyetleri ve geliştirme sürelerini katlamış olursunuz.

Sadece bir örnek üzerinden konuştuk, farklı bir anket formu olduğunu düşünün. İkinci bir şema oluşturmak ve verileri yazacak benzer bir sistem geliştirmek zorunda kalırsınız.
Yukarıda verilen örnekleri düşündüğümüz de nasıl bir yük ile karşı karşıya olduğumuz gün yüzüne çıkmaktadır. Schema-On-Read'in asıl faydası burada ortaya çıkar. Veriyi olduğu gibi yüklediğinizden dolayı (yazmak değil, yüklemek tabirini özelikle kullanıyorum) proje sürelerinin kısalmasını, maliyetlerin azalmasını dolayısıyla projenin başarılı olarak kapatılması olasılığını yükseltmiş olursunuz.



Hiç yorum yok:

Yorum Gönder