İlginizi Çekebilir
  1. Ana Sayfa
  2. T-SQL
  3. Veritabanı ve Okunaklı Kodlama İçin Tavsiyeler

Veritabanı ve Okunaklı Kodlama İçin Tavsiyeler

Merhabalar. Selamlar. Bu yazımda Veritabanı ve Okunaklı Kodlama İçin Tavsiyeler konusundan bahsetmek istiyorum.

Veritabanı ve Okunaklı Kodlama İçin Tavsiyeler

Merhabalar. Selamlar. Bu yazımda Veritabanı ve Okunaklı Kodlama İçin Tavsiyeler konusundan bahsetmek istiyorum. Biliyoruz ki herkes Entity Framework kullanmıyor. Bende o kullanmayanlardan biriyim. Projelerimin hepsinde sql tablolarını manuel modeller ve sorguları manuel yazarım. Benim gibi çalışan arkadaşlar için bir kaç tavsiye vermek amacı ile bu yazıyı yazmak istedim.

Başlıkta SQL yazmasına takılmayın. Bu tavsiyelerim her veritabanı için geçerli olacaktır.

 

Veritabanı ve Okunaklı Kodlama İçin Tavsiyeler

Projelerimizde veritabanı olmazsa olmaz gibi bir şeydir. Her projemiz bir şeyleri takip etme (stok cari vs. vs.) amacı gütmese de yine de bir takım verileri saklamak için veritabanı kullanmak zorunda kalıyoruz. Bu veri tabanının ne olduğu aslında önemli değil. Biz programcılar için bir noktalama işaretinin bile çalışmayı engelleyecek bir öneme sahip olduğu aşikar. Bu sebeple yazdığımız sorgularda (query) bu noktalama işaretleri yüzünden çok fazla hata yapabiliyoruz.

Bu vereceğim tavsiyeler işte böylesi küçük sorunlara karşı daha hızlı bir çözüm olması ve okunaklı olması amacı güdüyor.

Incorrext Syntax Near ","

Gibi hayattan soğutan bu hatalarla daha az nasıl karşılabiliriz? Nasıl minimuma indirebiliriz?

Otomatik Query Oluşturma

Diğer veritabanı programlarını bilmiyorum ama SQL Management Studio‘da bu işlem var ve çok sık kullanırım.

SQL Management Studio ‘da bir tablo üzerinde sağ tık yapın ve “Script Table As” > “INSERT To” > “New Query Editor Window” deyin. Açılan Query sayfasında o tabloya bir insert yapmak için gerekli query otomatik oluşmuş oluyor. Query’i kopyalıyoruz ve kod sayfamıza yapıştırıyoruz.

Her satırın başına ( +” ) ve sonuna ( ” ) ekliyoruz. Sorgumuzu bir string değişkene atıyoruz ve gerekli yerleri düzeltiyoruz. Yani VALUES kısmından sonraki satırlara verileri alacağımız nesneleri yazıyoruz.

Genelde kullanılan şekli aşağıdaki gibidir değil mi? Ne kadarda okunaksız. Birde burada 60, 70 kolon olduğunu ve böyle uzayıp gittiğini düşünün. Ne kadar zorlanırsınız? Arada bir virgülün eksik olduğunu düşünün… Ya da fazla olduğunu…

INSERT INTO [dbo].[Kullanicilar]([ku_kodu],[ku_adi],[ku_sifre],[ku_yetki])
     VALUES ('5','Mustafa BÜKÜLMEZ','123465','Administrator')

Şimdi yukarıda bahsettiğim şeyi yapalım ve görelim…

INSERT INTO [dbo].[Kullanicilar]
 	 ([ku_kodu]
	 ,[ku_adi]
	 ,[ku_sifre]
	 ,[ku_yetki])
VALUES (
	 '5'
	 ,'Mustafa BÜKÜLMEZ'
	 ,'123465'
	 ,'Administrator')

Böyle bir yazım şeklinde eksik veya fazla virgülü neredeyse anında bulabilirsiniz değil mi? Ama burada virgülleri kolon adlarının sol tarafında olmasına dikkat edin. Otomatik olarak solda geliyor ama bazen üzerinde düzenleme yapmamız gerekebiliyor. Sağ tarafında olursa pek bir anlamı kalmıyor.

Okunaklı Kod ve Sorgu

Benim kullanım şeklim bir adım daha ileri gidersek şöyle oluyor.

INSERT INTO [dbo].[Kullanicilar]
           ([ku_kodu]
           ,[ku_adi]
           ,[ku_sifre]
           ,[ku_yetki])
     VALUES
           ('5' -- <ku_kodu, nvarchar(50),>
           ,'Mustafa BÜKÜLMEZ' --<ku_adi, nvarchar(50),>
           ,'123465' --<ku_sifre, nvarchar(50),>
           ,'Administrator' ) -- <ku_yetki, nvarchar(50),>)

Bu şekilde yaptığımda hangi satırda hangi kolon bilgisi var ve olması gerekeni görebiliyorum. Üst kısım ile karşılaştırıp eksik kolon var mı görebiliyorum. Burada dikkat edilmesi gereken nokta son satırdaki parantezi unutmamak.. (–) yaptıktan sonra parantezde yorum olarak kalıyor ve parantez hatası alıyoruz. Bu yöntemi her zaman kullanmıyorum. Çok fazla kolonu olan tablolarda kullanıyorum.

Ayrıca genellikle bu yorum olarak işaretleme işlemini C# tarafında yapıyorum. ilgili texbox’u yazdıktan sonra kolon adı ve veri tipi kısmından önce // kullanıyorum.

Aynı şekilde Select, Update gibi tüm işlemler için gereken sorguları alabiliyoruz.

Ben C# kullandığım için Visual Studio’da şöyle görünüyor.

                comm.CommandText =""
                        + "  INSERT INTO [dbo].[Kullanicilar] "
                        + "       ( ku_kodu " 
                        + "       , ku_adi "
                        + "       , ku_sifre "
                        + "       , ku_yetki) "
                        + "  VALUES "
                        + "       ( '" + txt_kod.Text + "' "
                        + "       , '" + txt_adi.Text + "' "
                        + "       , '" + txt_sifre.Text + "' "
                        + "       , '" + cmb_yetki.Text + "'    )";

Yaşadığım şehir olan Kahramanmaraş’ta “İp Gibi” (Gergin bir ip gibi dümdüz) diye bir deyim vardır.  Tam uyuyor. 😀 Bu konuda ilk zamanlarda çok sıkıntı çektiğim için takıntılı oldum. Her virgül ve + aynı hizanda olmazsa rahat edemiyorum. 🙂 Mesleki deformasyon gibi bir şey. 🙂 

NOT: Buradaki yazıda bir SQL ‘de Entity Class Oluşturma dersini de inceleyebilirsiniz. Tablolarınızı SQL üzerinde bu şekilde modelleyerek ve sorgularınızı yukarıdaki gibi okunaklı olarak yazarak güzel kodlar yazabilirsiniz. 🙂

 

Kolonlarda Tablo İşaretçileri

Yukarıdaki örneklerde görebiliyorsunuz. Tablomun adı Kullanıcılar. Bu Kullanıcılar tablomdaki her kolon adının başında ( ku_ ) işaretçisi var. Bu işaretçi, bu kolonların Kullanıcılar tablosuna ait olduğunu işaret ediyor. 5, 10 tablolu projelerde önemsemeyebilirsiniz ancak büyük projelerde olması gerektiğini düşünüyorum. Çünkü projeler büyüdükçe, daha karmaşık konulara girmeniz gerekiyor.

Örnek olarak cari, stok, borç, alacak, çek, senet, banka, fatura, tahsilat gibi bir çok modülü olan bir projede bir carinin ekstresi’ni çıkarmak için kaç tane tabloya dokunmanız gerekiyor. Nasıl bir karmaşıklıkta sorgu yazmanız gerekiyor? Bu tabloların her birinde cari kodunun tutulduğu kolonun adı Cari_Kodu olduğunu varsayalım.

Cari Extresi’nde birleştirici nokta Cari_Kodu kolonudur. Ancak biz her tabloda aynı adı verdiğimizde, where kısmını veya iç sorguları hazırlarken hangi tablonun Cari_Kodu’nu, hangi tablonun Cari_Kodu’na eşitlediğimizi nasıl anlayacağız?

  • Tahsilatlar, tah_Cari_Kodu
  • Bankalar, ban_Cari_Kodu
  • Faturalar, fat_Cari_Kodu
  • Çekler, cek_Cari_Kodu

gibi tablo işaretçileri ile kolon adlarını yazdıktan sonra where kısmını hazırlarken en ufak bir şüphe olmadan sorgumuzu yazabilir ve yanlış kolon eşitlemeleri yüzünden saçma sapan sorunlar ile uğraşmak zorunda kalmamış oluruz.

 

Kolon Adları ve Veri Tipleri

Kolonları hazırlarken, aşırı kısaltma kullanmamaya çalışın. Neden kısaltma kullanmak zorundasın ki? Örnek olarak bir kısaltma kullanalım ve bir kolon adı yazalım. fat_sat_ack1 bu kısaltmadan ne anlıyorsunuz? Bu kolonun amacı fatura 1. satır açıklaması idi. Bu kolonu kısaltmalı yazsam ne kaybederim? fat_satir_acikalama1 olarak yazsam ne kaybederim?

Net olarak bilmemekle ve yaptığım deneme ile 60 karakter uzunluğunda bir kolon başlığı yazabildim. Şahsen 60 karakter uzunluğunda da bir kolon başlığı yazmamı gerektirecek etiket düşünemiyorum. Yani aşırı kısaltma yapmadan yazabilecek kadar geniş bir alanımız var.

Aynı şey tablo adları içinde geçerli. Aşırı kısaltmalardan kaçınmamız gerektiğini düşünüyorum. CARI_HESAP_ADRESLERI olarak düşündüğümüz bir tabloyu CARI_HSP_ADR  gibi bir kısaltma ile yazmamızın hiçbir anlamı olmadığını düşünüyorum.

 


Programlamada SQL Sorgularını Okunaklı Yazmak yazımda bu kadardı arkadaşlar. Bu sektörde olduğum süre boyunca elde ettiğim tecrübelerden derlenmiş bir kaç nacizane tavsiyemdir. Elimden geldiğinde okunaklı kod yazmaya çalışıyorum ve çevremdekilere de veritabanı ve okunaklı kodlama konusuna dikkat etmeleri için tavsiyeler vermeye ve almaya çalışıyorum.

Dürüst olacağım, benden başkası anlamasın diye her şeyi aşırı kısaltmış ve şifreleri şeyler yazanlara çok küfür ediyorum.  Bu bir profesyonellik değildir. Tamam, başkasının anlamaması egolarını tatmin edebilir ama başka neye yarar? Böyle insanların arkasından herkes küfür eder. Bu sadece bana özgü bir şey değil.

Profesyonellik, başkasının anlayamamasını sağlamak değil, herkesin anlayabilmesini sağlayabilmektir.

Herkesin amacı bu olsaydı, internette tek bir kaynak bulamazdık. Bende alacağım tepkilere rağmen bu yazıyı ve bu yoruma zahmetine girmezdim.

Diğer yazılarıma gitmek isterseniz buraya tıklayabilirsiniz.

Bol kodlu günler… ^_^

Sağlıcakla ve takipte kalın.

Yorum Yap

Yazar Hakkında

Liseden, Ağ Sistemleri ve Yönetimi bölümünden mezun oldum. Üniversiteden (2 yıllık), Bilgisayar Programcılığı bölümünden mezun oldum. Şuanda da AÖF, Yönetim Bilişim Sistemleri bölümünde okumaktayım. Uzmanlık alanlarım; Windows Sistemleri, HTML, CSS, C# ve SQL’dir. Hobi olarak uğraştığım genel konular, Photoshop, After Affects, Corel Draw’dır. Film, YABANCI dizi, Anime izlemeyi ve Manga okumayı severim. Arkadaşlarımla yürüyüş yapmayı ve grup olarak aktivitelere gitmeyi severim. Geri kalan zamanlarımın tümü bilgisayar karşısında geçer.

Yorum Yap

Yorumlar (1)

  1. Alper Karaman

    Birilerinin SQL konusunda canını sıkmışlar 😀 abi bu kadar takma. Bende hep derim her yiğidin bir yoğurt yiyişi vardır diye.