I compiled the pdf version of this online book. You can print and use as a desktop reference…

Click here to get the book…

Note that most updated book is online version.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Bildiğiniz gibi, ulaşabileceğiniz en iyi cakephp kitabı şuradaki online kitaptır.

Bir süre önce bu kitabın yazıcı çıktısını almak için pdf  haline getirmiştim. İsteyen arkadaşlar aşağıdaki linkten kitabı indirip bastırabilir.

Tıklayın….

En güncel halinin online versiyon olduğunu unutmayın.

Codeigniter kullanmayı bıraktığım için (konunun çoğu ilgilisi gibi), CI ile ilgili gelişmeleri, Fatih Bazman kardeşimin başarıyla yürüttüğü codeigniter.gen.tr ‘den takip ediyorum. Kendisinin şuradaki yazısı beni heyecanlandırdı. Çünkü Codeigniter 2.0 ile birlikte bazı önemli özellik ve kütüphanelerin frameworke eklenmesini bekliyordum. Ancak şuradaki resmi dokümana bakılırsa (şimdilik), birkaç değişiklik dışında pek de öyle heyecan verici bir gelişme yok.

Bahsedilmeye değer iki önemli konu var;

1) Php 4 desteğindeki ısrardan vazgeçilip, php 5 ‘in avantajlarının kullanılmaya başlanmış olması. (Açıkçası çok geç kalındı. Neredeyse php 6 çıkmak üzere ama değerli ellislab çalışanları, lütfedip yeni geçtiler. Ancak zararın neresinden dönülse kardır diyerek bu konudaki eleştirimi fazla uzatmıyorum.)

2) Security library eklenmiş: daha önce de xss filtreleme vs gibi özellikler olmasına rağmen, buna CSRF koruması da eklenerek daha da iyileştirilmesi iyi olmuş.

Bu iki konu dışındaki diğer maddeler, ara versiyonlarda yapılabilecek sıradan değişiklikler ve php 5 in getirdiği yeniliklerin uyarlamasından ibaret.

Özellikle hemen hemen bütün frameworklerde mevcut ulan kullanıcı yönetimi, yine dışarıda bırakılmış. Bu konuyu, resmi forumlarında da defalarca anlatmaya çalışmamıza rağmen bir türlü anlamak istemiyorlar (ya da anlamak işlerine gelmiyor anlaşılan). Basit bir auth uygulamasını eklemek bu kadar mı zor? “Kendi kütüphaneni yazabilirsin” dediler, doğrusunun CI core içinde olması gerektiğini nedenleriyle anlattık. Tekrar burada yazmaya gerek duymuyorum…

Kısacası bu yeni versiyona 2.0 yerine, 1.8 dense de olurmuş. Yukarıdaki iki konu dışında radikal bir değişiklik yok. Kohana’yı bırakıp Codeignter 2.0 kullanmak için hiçbir sebep göremedim.

Umarım resmi olarak yayınlandığında, şimdi görülenden daha güzel bir framwork ile karşılaşırız. Şu an için fazla eleştiri yapmak pek doğru değil.

Sevgiler

Tabi böyle bir soruyu, genel olarak herkesin kabul edebileceği bir takım sonuçları arştırmak için ortaya koymak çok yanlış. Bu soru, olsa olsa bireysel olarak programcı bazında ele alınabilir. Hatta programcı bazından ziyade, proje bazında ele alınması daha doğrudur. Her zaman aynı aracı kullanmak imkansız. Dolayısı ile burada ve daha sonra kouyla ilgili yazacaklarım sadece benim fikirlerim olup, mutlak olarak genel bir doğru olduğunu idda etmiyorum.

Bu iki küçük açıklamayı yaptıktan sonra gelelim konuya.

Efendim, bir programcı olarak yıllardır, Microsoft’a olan alerjim nedeniyle, sürekli olarak uzak kaldığım ve görmezden geldiğim .net ten bahsedeceğim. .Net e karşı şimdiye kadar uzak durmamın kendime göre bazı çok önemli geçerli sebepleri oldu. Hep söylenir; açık kaynak olması, kaynak bolluğu, açık kaynak projelerin ve kod örneklerinin sağladıkları, tamamen ücretsiz olması vs vs… Php nin güzelliklerini sıralamayacağım, çünkü liste çok uzun. Daha çok, son zamanlarda .net e daha sıcak bakmama sebep olan ve hatta önümüzdeki dönemde, ana geliştirme platformu olarak kendisini tercih edecek olmama sebep olan, özelliklerden bahsedeceğim.

1) Asp.Net ‘de en az PHP kadar ücretsizdir:

Evet yanlış okumuyorsunuz. Hatta bana göre Asp.Net, programcı için, Php den daha ücretsiz.

Bilindiği gibi, Visual Studio Express ürünleri tamamen ve her türlü kullanım için ücretsiz. Örneğin Visual Web Developer Express ‘i ayrıntılı incelemeyen php programcıları varsa şiddetle tavsiye ederim. Öyle ki bu ücretsiz araç, Php camiasında karşılığı olmayan muhteşem bir araç. Kendisi, 300 dolardan başlayan php editörlerinden dahi kat kat daha üstün.

Ayrıca sql server express de tamamen, her türlü kullanım için ücretsiz. Web programcılarını %99,99′unu ilgilendiren tek kısıtlaması ise her bir veritabanı dsoyasının ~4 gb ‘ı geçemeyecek olması ki, bu rakam çoğu web projesi için çok yeterli. Zaten bu rakamı geçen bir veritabanını barındıran projeniz mevcut ise, bu tür yatırımları her durumda yapmanız gerekecek. Ancak biz, ortalama bir web programcısından bahsediyoruz. Dev projelerden değil….

Bir programcı olarak en doğal hakkınız, kodlarınızı kapatabilmek… Php de bu biraz zor. Yani php nin kendi dahili araçları ile birşeyler yapılabilir ancak yapmakla, yapmamak arasında hiçbir fark yok. Adam gibi bir şey yapacaksanız, ioncube, zend encoder, gibi araçlara yüzlerce dolar para vermek zorunda kalacaksınız. Bu programların yıllık fiyatları 200 dolar ile 600 dolar arasında değişiyor ki neredeyse dev gibi bir Visual Studio Professional’ a verdiğiniz paradan daha yüksek. Üstelik php camiasında kod güvenliğini sağlayan, ücretsiz (ama adam gibi iş yapan) bir araç yok. Ancak durum .net tarafında çok farklı; Çok ciddi iş yapan araçlar (dotfuscator vs) mevcut ve bunların community editionları tamamen ücretsiz ve bir web programcısı için fazlasını veriyor. Tabi bu araçların 1500 dolara kadar çıkan sürümleri de mevcut ancak bu ücretli sürümlerini, ioncube vs ile karıştırmamak gerekir. Ayrıca, php de olduğu gibi sunucuya herhangi bir eklenti vs yüklemeniz gerekmiyor.

2) Aynı programlama dili ve programlama aracı ile hem masaüstü, hem web hem de mobile programlama:

Programcının hitap ettiği müşteri portföyünü inanılmaz derecede arttıran bir özellik bu. Yani .net kullanıyorsanız artık sadece web projelerini değil, her üç konuda da ihtiyaçları olan kişi ve kurumlara hizmet üretebiliyorsunuz. Üstelik bunların üçünü de aynı projede birleştireren projeleri de çok kolayca gerçekleştirebiliyorsunuz. Yani hem web ayağı, hem masaüstü ayağı, hem de mobil cihazlar ayağı olan bir proje düşünün… Böyle bir işi tek bir programlama dili ve tek bir programlama aracı ile yapabiliyorsunuz.

3) Asp.net ‘de de, php yi, hiç aratmayacak derecede açık kaynak proje var:

Hemen hemen her konuda bir hazırlanmış açık kaynak proje mevcut. Hadi canım diyenler, şurayı incelesin.

4) Hızlı proje geliştirme ve zamandan tasarruf:

Visual Studio, resmen bir sihirbazlık aracı gibi. Kimisi buna karşı. Yani “programcı kodları kendisi yazmalı, ayrıntılarla uğraşmalı” mealindeki kriterlerle visual studio ya soğuk bakıyor. Ancak bence bir programcı kendi zamanını efektif yönetebilmeli. Daha az zamanda ve daha kısa sürede proje hazırlamayı sağlayacak her türlü fırsatı akıllıca değerlendirebilmeli. Her türlü işte, notepadi açıp kod yazmayı marifet sayanların saf olduğunu düşünüyorum. Evet biraz ağır oldu bu tanımlama, ancak öyle malesef. Yani sistem programlama yapmıyoruz. Klasik web programlamada  kodları tek tek yazmakta ısrar etmenin nesi makul? Deniliyor ki programlama öğrenilemiyor… Önemli olan, programcının işi nasıl yaptığı değil, yazılımı kullanacak olanların ihtiyaçlarını ne ölçüde giderebildiğidir.  Notepad ile web projesi hazırlamayı  savunan bir programcının pratikliği, projeye bütün olarak bakmasını ve müşteri ihtiyaçlarını hep göz önünde bulundurmasını sağlayacak kadar gelişmiş değildir.  Birileri notepad ile, herşeyi tek tek elle yazarak örneğin 3 ayda iş çıkarırken, diğeri aynı işi 2 haftada yapar, kalan zamanda müşteri ihtiyaçları doğrultusunda projesini tekrar tekrar gözden geçirip müşteriye en uygun hale getirir. İkincisi için, ne de olsa, önemli olan projenin kendisidir. Programlama sadece bir araçtır. Kısaca akıllı programcı bir sürü angarya ayrıntı ile uğraşmaktansa, daha çok, projeye bütünsel olarak bakmayı tercih eden programcıdır.  İşte .net bunu sağlıyor programcıya. Amaç müşteri ihtiyacına en uygun çözümü sunmaktır. Bu pencereden baktığınızda Asp.net, php den fersah fersah önde…

5) Devasa bir .net kaynak kütüphanesi:

Php de de çok zengin bir kaynak sözkonusu ancak bazen tam bir kaynak çöpüğü arasında boğulduğunuzu hissetmenizde olası. Ne seviyedeki programcıların yazdığı, ne kadar doğru olduğu tartışmalı olan bir kaynak kütüphanesinden bahsediyoruz php tarafında… Fakat .net tarafında resmi olarak, çok derli toplu bir şekilde hazırlanmış, daha profesyonel bir kaynak kütüphanesi mevcut.

6) .Net, çok daha derli toplu bir programlama ortamı sunuyor:

Bu konu php de en sevmediğim husustur. Oysa .net ile, sunduğu araçlar ve yaklaşım tarzı nedeniyle ister istemez. profesyonelce proje geliştiriyorsunuz. Yani benzetme yapmak gerekirse, php ihtiyaç duyuldukça ek kat çıkılan yığma bir bina gibi, .net ise çelik konstrüksiyonlu bir gökdelen gibi görünüyor.

Liste uzar gider….

Tekrar belirmek isterim ki, herkesin yoğurt yeyişi farklıdır. Bana göre bu ise, size göre farklıdır. Bu yazının amacı web  programcısına (özellikle php programcısına) bir pencere açmaktır. Yoksa illa ki bu doğrudur demek değildir. Php de çok esnek ve kullanması zevkli bir dil. Tabii ki ihtiyacım olacak ve php yi kullanmaya devam edeceğim. Ancak yukarıda saydığım nedenle, bana göre çoğu zaman, asp.net daha uygun bir araç…

Saygılarımla

Hata bildirimi, istekleriniz, destek ve diğer sorularınız için bu sayfanın altındaki yorumlar bölümünü kullanabilirsiniz.

Proje sayfası: http://www.ibonette.com/phpsch-source-code-highlighter-kaynak-kod-renklendirici

Lisans: Açık kaynak kodlu (GNU/GLP)

Sourceforge.net: sourceforge.net/projects/phpsch/

İndirmek için: https://sourceforge.net/projects/phpsch/files/phpsch/phpsch-1.0.rar/download

Teşekkür: php, jquery, chili

_____________________________________________________________

English Version

PHPSCH is web based source code syntax highlighter. You can use your own template for highlight. It developed using php, javascript(jquery).

Supported programming languages: ‘php’, ‘cplusplus (C++)’, ‘csharp (C#)’, ‘css’, ‘delphi’, ‘html’, ‘java’, ‘javascript’, ‘mysql’

Programming languages: php  and javascript

GUI languages: Turkish, english, german (you can also add your language)

Project page: http://www.ibonette.com/phpsch-source-code-highlighter-kaynak-kod-renklendirici . You can use this page for support, requests etc…

License: Open source (GNU/GLP)

Sourceforge.net: sourceforge.net/projects/phpsch/

Download: https://sourceforge.net/projects/phpsch/files/phpsch/phpsch-1.0.rar/download

Credits: php, jquery, chili

_____________________________________________________________

Ekran Görüntüleri   /   Screenshots

Deprecated: Assigning the return value of new by reference is deprecated in .....

Bu hata, genel olarak, php 4 uyumlu olarak geliştirilen uygulamalarda alınıyor.  Onaylanmayan fonksiyonların kullanıldığı betikler bu hatayı veriyor. Yani artık 5.3 ile birlikte tavsiye edilmeyen ve php 6.0 kaldırılacak olan fonksiyonlar. Örneğin; ereg, eregi, ereg_replace, split, spliti, sql_regcase… Bu fonksiyonlar halihazırda kullanılabilir durumda ancak yukarıdaki hatayı üretiyor. Yani, Php 5.3   ile birlikte değişen (php.ini) hata raporlama ayarları nedeniyle bu hata alınıyor.

Standart php kurulumlarının üzerinde modifikasyon yapılması hiç işime gelmediği için bana en uygun çözüm şu an için, php 5.2.x ‘e dönmek oldu. Aksi halde php 5.3 versiyonuda php.ini içindeki hata raporlama ayarları ile uğraşarak düzeltme yoluna gitmeye kalksam, kullanıcıların da bu düzenlemeyi yapması gerekecek ki çoğu kullanıcı için bu mümkün değil.

Ayrıca yayındaki php 4  uygulamalarınızda bu hatayla karşılaşma olasılığınız düşük, çünkü php 5.3 versiyonu nispeten yeni bir sürüm olduğu için zaten sunucularda yüklü olmayacaktır.

Bunun dışında diğer bir çözüm ise, (gördüğüm kadarı ile) uygulamarınızı php 4 uyumluluğunu bir kenarıya bırakıp tamamen php 5 uyumlu uygulama geliştirmek. Fakata burada eğer benim gibi cakephp vs gibi php 4 uyumlu frameworkleri kullanıyorsanız, istediğiniz kadar php 5 uyumlu yazılım geliştirin, frameworkün kendisininde bu şekilde düzeltilmesi gerekecektir.

Eğer localdeki geliştirmelerinizde wamp kullanıyorsanız şuradan php 5.2.x başlığı altındaki dosyalardan istediğinizi indirip mevcut wamp kulumunuzun üzerine kurun. Daha sonra wamp menüden php/versiyon bölümünden yeni yüklemiş olduğunuz php 5.2.x versiyonunu seçerek apache’yi yeniden başlatmanız gerekiyor.

Ancak bana kalırsa artık onaylanmayan fonksiyonları kullanmaktan hızla kaçınmaya başlamak lazım. Çünkü php 6 ile bu fonksiyonları kullandığınız betikleriniz çalışmayacaktır. Şuradan, artık önerilmeyen (deprecated) özellikleri-fonksiyonları ve bunların yerine kullanabileceğiniz fonksiyonları  inceleyerek gerekli önlemleri alabilirsiniz.

Şimdilik durum bu. Konuyla ilgili uzun uzadıya ilgilenecek vaktim yok malesef.  Konuyla ilgili nihai çözüm php tarafondan gelemesi gerekiyor. Belki de php tarafından bilinçli olarak yapılmış olabilir bilemiyorum. Önümüzdeki günlerde daha mantıklı çözümler buluruz. Bu olana kadar ihtiyacı olan için, yukarıdaki yazı yararlı olur umarım.

Saygılar

Resmi Olmayan (Pratik) Yaklaşım, genellikle oldukça kullanışlı bir veritabanı tasarımı üretir. Bu, çoğu veritabanı tasarımcısının kullandığı yöntemdir. Bir sonraki yazımda anlatmaya çalışacağım “resmi yaklaşım”, sıfırdan veritabanı oluşturmaktan çok, “resmi olmayan” yaklaşımla oluşturulan veritabanı tasarımının sınanması ve doğrulanması için kullanılır.

Lafı fazla uzatmadan anlatıma geçiyorum.

Ana Varlıkların Belirlenmesi

Her uygulama bir takım varlıklar içerir. Bu varlıkların özellikleri ve birbiriyle ilişkileri uygulamanın temelini oluşturur.  Bu aşamada sadece uygulamanın üst düzey nesneleri ile ilgilenmek gerekir. İleriye dönük bazı fikirlerinizin olması mantıklı olsada, bu aşamada, her varlığın özniteliklerini düşünmek için fazla ısrarcı ve aceleci olmayın.

Örnekler;
Ders planlama sistemi: öğretmenler, öğrenciler ve dersler…
Havayolları bilet sistemi: müşteriler, uçuş personeli, seferler, uçaklar, koltuklar, havalimanları, kapılar…
Futbol ligi: oyuncular, takımlar, sahalar, oyunlar, çalıştırıcılar, hakemler…
Sipariş sistemi: müteriler, tedarikçiler, müşteri siparişleri, satın alım siparişleri, ürünler, müşteri faturaları, depolar…

Her Ana Varlık İçin Bir Tablo Oluşturulması

Bir önceki aşamada belirlenen her ana varlık için bir tablo oluşturulur. Her tabloya, açıklayıcı ama kısa ve kolay yazılıp hatırlanan bir isim verin.

Örnek;
Satılan ürünlerin tanındığı tabloya “urun” adı verilebilir.

Her Ana Varlık İçin Bir Anahtar Seçilmesi

Ana varlıkları benzersiz bir biçimde tanımlayacak bir alan belirleyin. Bu, tablonun birincil anahtarıdır (primary key). Birincil anahtar boş olamaz ve tablodaki her kaydın farklı bir birincil anahtarı olmalıdır. Yani birincil anahtara göre kayıt sorgulaması yapıldığında sadece bir kayıt döndürmelidir.

Birincil anahtar olarak ne kullandığınız bilgisayar açısından farketmese de, varlığın doğasında bulunan ve benzersiz, tekrarsız bir özellikle tanımlamanız daha doğru olur. Yani örneğin “kitap” tablosunda, sizin belirleyeceğiniz uydurma bir alanı birincil anahtar olarak belirlemek yerine,  (eğer mümkünse) her kitabı kendilinden ve doğal olarak tanımlayan ve benzersiz olan “ISBN” ‘i (uluslararası standart kitap numarası) birincil olarak tanımlamak daha uygun olur.

Diğer taraftan kimi doğal anahtarlar, yukarıdaki kitap örneğinde olduğu gibi, birincil anahtar olarak kullanmaya pek uygun olmayabilir. Çok uzun, büyük-küçük harf duyarlı, türkçe karakterler içeren, boşluk ve noktalama içeren anahtarlar genellikle kötü veritabanı anahtarı olarak algılanır. Bu tür durumlarda, 1,2,3 gibi ya da otomatik artan bir alanı birincil anahtar olarak belirlemek daha mantıklı olur.

Her Ana Varlık Tablosuna, Varlık Özniteliklerinin Eklenmesi

Uygulamanızda tanımladığınız ana varlıkların (tabloların)özniteliklerinin belirlenmesidir. Örneğin “musteri” tablosunda, ad, adres, sehir, ulke, telefon, faks vb özellikler tabloda bir alan (saha ya da sutun da denir) olarak tanımlanır.

Bu aşamada, basılı formlar, dokümanlar, uygulamayı kullanacak olanların görüşleri vs bu konuda önemli ipuçları verir. Ancak her uygulamada farklılık göstereceğini unutmamak lazımdır. Yani bir uygulamada “musteri” tablosu, farklı özniteliklerden (alanlardan) oluşmakta iken, başka bir uygulamada daha farklı özniteliklerden oluşabilir.

Tekrarlanan Öznitelikler için Ek Tablolar Oluşturulması

Tablo özniteliklerini belirlerken, bazı alanların tekrarlanan veriler içerebildiğini göreceksiniz.
Örneğin; “kitap” tablosunu tanımlarken, “yazar” özniteliğinin (alanının) içeriğinin, bazı kayıtlarda (satırlarda) tekrarlanan bir yapıda olabileceğini görürsünüz. Bu durumda, “kitap” tablosundaki tekrarlanan “yazar” alanını, “kitap” tablosunun dışına alarak “yazar” adında ayrı bir tablo tanımlamanız gerekir.

Her Alanın (özniteliğin), Birincil Anahtarın Özniteliği Olduğundan Emin Olun

Birincil anahtarıni tablodaki her alan için mantıklı bir arama sağladığından emin olunması gerekir.

Örneğin;
uye_kodu (birincil anahtar)
uye_adi
uye_adresi
uye_grup_kodu
uye_grup_adi
şeklindeki bir “uye” tablosunda, tabloya ait olmayan alan, “uye_grup_adi” alandır. Bu alan “uye_grup” tablosunun bir alanıdır. Bir başka deyişle “uye_grup_adi” ‘nı bulmak, “uye_kodu” alanını sağlamayı gerektirmez. “uye_grup_adi” ‘nı bulmak için “uye_grup_kodu” alanını sağlamak gerekir ve dolayısı ile “uye_grup_adi” alanı, “uye_grup” tablosuna aittir. “uye_grup” tablosunun birincil anahtarı, “uye_grup_kodu” dur.

Peki belirli bir üye için üye grubu adını nasıl belirleriz? Bu durumda, “uye” tablosundaki “uye_grup_kodu” alanına bağlı olarak, “uye_grup” tablosuna bağlanarak üye kodu bilinen kaydın “uye_grup_adi” ‘nı alırız.

Tablolar Arasındaki İlişkilerin Gözden Geçirilmesi

Her bir varlığa karşılık gelecek ayrı bir tablo oluşturduk. Şimdi ise tıpkı gerçek hayatta olduğu gibi, veritabanında  da, varlıkların (yani tabloların) birbiri ile olan ilişkileri belirlenmelidir.
Bu işlem kısaca, birbiri arasında ilişki olan tabloların, ilişki tanımlaması amacıyla, ortak alanlarının belirlenmesi anlamına gelir.

Bir önceki adımdaki örnekte, “uye” tablosu ile “uye_grup” tablosu arasındaki ilişki, ortak alan olarak kullanılan “uye_grup_kodu” alanı ile sağlanır.

İki farklı tablodaki (ilişki kurmakta kullanılacak ortak) iki alan, aynı anlama sahipse, ikisine de aynı adı vermek tavsiye edilir. Yani grup kodu ile iki tablo arasında ilişki belirlerken, “grup_kodu” tablosunda “uye_grup_kodu” adını kullanırken, “uye” tablosunda “kullanıcı_grup_kodu” adını kullanmak, veritabanının çalışmasını engellemez ancak kullanımı güçleştirerek karmaşaya neden olur.

Çok genel olarak yukarıdaki şekilde özetlenbilecek “resmi olmayan (pratik) yaklaşımı” kullanarak, düzgün tasarlanmış bir veritabanı tasarımına ulaşabilirsiniz. Ancak belirmem gerekir ki, burada maddeler halinde kısaca belirttiğim husuları biraz daha ayrıntılı olarak incelemek ve iyice sindirmek gerekir. Çünkü bu adımlar, uygulanmaya kalkıldığında, her adımda belirtilen husuların sağlandığını sanıp gözünüzden kaçan noktalar olduğunun farkına varamayabilirsiniz. Örneğin “Tekrarlanan Öznitelikler için Ek Tablolar Oluşturulması” adımını, veritabanındaki tüm tablolara eksiksiz olarak uyguladığınızı düşünebilirsiniz ancak gözünüzden kaçanlar olabilir. Özellikle bir sürü tablodan oluşan büyükçe uygulamaların veritabanlarını tasarlarken her bir adım uzun uzun ve dikkatle veritabanı üzerinde çalışmayı gerektirir.

Konuya uzak olan kişilere, yukarıdaki bazı anlatımlar kafa karıştırıcı gelebilir. Ancak aslında öyle olmadığını unutmayın. Karmaşık gelen anlatımları, kavrayabilmek için kendinize zaman verin, araştırın, sorun… Kısa süre içinde kafanızda canlanacak ve tam olarak ne anlama geldiğini anlayacaksınız. Önemli olan adımların ne anlama geldiğini kavramaktan ziyade, fiili olarak veritabanı üzerinde çalışırken bu adımları tam olarak gerçekleştirebilecek konsantrasonu gösterebilmektir.

Bir sonraki yazımda “resmi yaklaşım” dan bahsedeceğim. Bu konu, yukarıda anlattıklarımdan çok farklı şeyler olmayıp, yukarıdaki adımlarla pratik bir şekilde üretilen veritabanı tasarımınızın sağlamasını yapmanızı sağlayan bir araç olarak kullanacaksınız.

Sevgilerimle

Programlamaya yeni başlayan amatör programcılar, uygulama geliştirirken  genellikle kodlar (php vs.) üzerinde dururlar. Oysa ki kod kısmı işin en son kısmı olup, öncesinde  yapılan bir takım analiz ve hazırlıklar sonucunda üretilen uygulama gereklerini, gerçekleştirmek üzere yazılır ve hangi programlama dilini kullanırsanız kullanın çok fazla farklılık göstermezler. Programlama dili değiştiğinde temel olarak değişen, yazım kurallarıdır. Yine aynı döngüleri, aynı mantıksal sınamaları, aynı karşılaştırmaları yaparsınız. Sadece yazım şekli değişir ancak temelde hangi dili kullanırsanız kullanın kodunuz aynı işleri yapar ve aynı sonuçları üretir. Tabi ki istisnaları da olmakla birlikte genel olarak durum böyledir.

Kodlama ve programlama dili konusunu çok basite indirgemek için değil, kodlamaya başlamadan önceki analiz ve planlamalara özel bir vurgulama yapmak için yazdım bunları. Yoksa tabi ki programlama dili çok önemlidir. Fakat yine de programlama dili seçimi, öncesindeki analiz çalışmalarının sonucunda yapılmalıdır.

Uygulama geliştirmenin ilk ve en önemli aşaması olan analiz ve planlama ‘nın pratikte üç önemli ayağı vardır;
* Durum tespiti ve ihtiyaç belirleme (iş analizi),
* Veritabanı tasarımı,
* Algoritma geliştirme,

Bunların herbiri, üzerinde uzun uzun ve ayrıntılı olarak çalışılması gereken ve her programcı (ya da proje yöneticisi) tarafından iyice öğrenilip uygulanılıyor olması gereken çok önemli konulardır. Bu konulardan teorik olarak bahseden ve bir takım yöntem ve kuralları vurgulayan bir sürü yazılı kaynak olmasına rağmen, asıl beceri ve bilgi, programcının zaman içinde edindiği tecrübeleri sayesinde oluşur. Yani uygulama geliştirdikçe ve özellikle kaliteli bir proje ekibi içinde  mesai yaptıkça, programcı, pratik olarak bu becerileri kazanır. Programcılık işinin literatürden ziyade usta çırak ilişkisi ile öğrenilen taraflarından birisi de budur.

Üzerinde düşünmeden hazırlanan bir veritabanı üzerinde çalışmak (sorgulama vb), zaman geçtikçe çok zorlaşabilmektedir. Örnek vermek gerekirse; gelecekte programcıdan istenen basit bir rapor, sırf veritabanı düzgün tasarlanmadığı için imkansız ya da çok zorlayıcı bir iş haline gelebilir. Bunun yanında, düzgün tasarlanmayan veritabanı, uygulamanın genişletilebilir olmasını büyük ölçüde baltalar. Örneğin ileride programcıdan istenen bir ek modül, yine sadece veritabanı düzgün tasarlanmadığı için imkansız ya da çok zorlayıcı bir iş haline gelebilir. Hepsinden önemlisi düzgün tasarlanmayan veritabanı, veri tutarsızlığı, tekrarlanan veriler gibi bir sürü çarpıklıktan oluşan bir çorbaya döner. Böyle bir veritabanı, zaman içinde, yukarıda bahsettiğim sorunların birbirini tetiklediği ve büyüttüğü bir kabus haline gelir. Programcı kendini, bitip tükenmek bilmeyen bir sürü anlamsız sorunlardan oluşan kısır bir döngü içinde bulur kendini.

İşte bu nedenle, uygulamayı kodlamaya başlamadan önce, üzerinde çalışacağınız veritabanını çok iyi tasarladığınızdan emin olmalısınız.

Bu yazımda ve devam eden birkaç yazımda, en önemli ayaklardan birisi olan “veritabanı tasarımı” konusunu ele almaya çalışacağım. Bunu yaparken teorik ve genel kabul görmüş kuralların yanında, pratik ve konununun özüne yönelik kısımlarından da bahsedeceğim.

Veritabanı tasarımı konusunda temelde iki yaklaşım mevcuttur;

Resmi Yaklaşım;

İlişkisel veritabanı oluşturulması/tasarlanması sürecinde, bir takım normalleştirme kurallarını(derecelerini) ifade eder. İlk olarak E.F.Codd tarafından kullanılan bu yaklaşım günümüzde çok geniş bir sorun yelpazesine uygulanabilir bir veritabanı modelini ortaya çıkarmıştır. Uzmanlar tarafından bir çok normalleştirme derecesinden bahsedilsede ilk beşi genel kabul görmüş ve resmileşmiştir. Ancak şahsen belirtmek isterim ki “resmi yaklaşım” olarak bahsedilen bu yöntem pratikte veritabanı tasarımı yaparken kullanmaktan ziyade, aşağıda bahsettiğim “resmi olmayan tasarımın” sınanması ve doğrulanması için kullanılır.

Resmi olmayan (pratik) yaklaşım;

Programcının zaman içinde edindiği bilgi ve deneyimleri sonucunda geliştirdiği veritabanı tasarımı yaklaşımını ifade eder. Programcıdan programcıya ufak tefek farklılıklar gösterse de, veritabanı genel olarak belli başlı adımlarla tasarlanır. Bunlar “resmi yaklaşım”dan daha pratik ve somut adımlardır.

Özetlemek gerekirse;

Resmi olmayan yaklaşımla somut olarak ortaya konan veritabanı, resmi yaklaşımla sınanarak doğrulanır. Uygulamanının veritabanı tasarımı ayağındaki genel süreç bu şekildedir.

Devam eden yazılarımda, yukarıda bahsettiğim “resmi olmayan” ve “resmi yaklaşım” bahsetmeye çalışacağım.

Sevgilerimle,

NOT: Yazının ikinci bölümü için:
Veritabanı Tasarımı-2: Resmi Olmayan (Pratik) Yaklaşım

Codeigniter hakkında özgün, çok kaliteli ve her geçen gün ciddi emek harcanarak geliştirilen içeriğiyle bu site, özel olarak bir yazının konusu olmayı hak ediyor. Özellikle kaynak belirtmeden ordan burdan kopyla/yapıştır şeklinde içerik oluşturulan internet camiasında, bu tür özgün içerik barındıran ve emek harcanan siteleri gördükçe mutlu oluyorum.

Kendileri codeigniter türkçeleştirme konusunu da versiyon çıktıkça hızla yenileyerek çok başarılı bir şekilde takip ediyor. Codeigniter türkçe dil dosyalarını sitelerinden edinebilirsiniz.

Codeigniter ile ilgilenenler, bu siteyi mutlaka takip etmeli ve hatta sık kullanılanlarına eklemeliler.

Bu siteyi yayınlayan  fatigue isimli kardeşimi şahsen tanımasam da, internette, codeigniter türkçe içerik konusunda oldukça aktif olduğunu görüyorum. Kendisini emeklerinden dolayı tebrik ediyorum.

Bunun yanında tüm programlama dillerini değil, sadece web programlama için kullanılabilecek programlama dillerini değerlendireceğim. Karşılaştırma için java, php, python ve c# dillerini seçtim. Bunlar en yaygın olarak kullanılan diller olmasına rağmen, isteyenler aşağıdaki tabloya, bunların dışında ruby vs gibi dilleri de ekleyebilirler.

Değerlendirmemi 19 adet kritere göre, en yüksek 100 olmak üzere, puanlandırarak yaptım. Belirlediğim puanlar benim kendi görüşlerim olup, kişiden kişiye değişebileceğini kabul ediyorum.

Bu ve buna benzer tabloların içerdiği tüm kriterlerin toplamına göre seçim yapılabileceği gibi, projede diğerlerine göre çok önemli olan sadece birkaç kritere, hatta tek kritere göre dahi seçim yapılabilir. Örneğin geliştirme araçlarının programcıya sunduğu kolaylaştırıcı özellikler projenizde hayati önem taşıyorsa, diğer tüm kriterler göz ardı edilerek Visual Studio ile C#  seçilmesi, gayet mantıklı bir karar olabilir.

Toplam puanlara göre en makul programlama dili java olarak görünüyor. Ancak tekrar belirtmek istiyorum; projenize göre, kendi gerçeklerinize göre sonuçlar değişecektir. Bu çalışmayı, kendi çalışmanızı yaparken sadece başlangıç noktası, kılavuz olarak dikkate alınız lütfen.

Sevgilerimle,