Objektif bir gorus degil ama data buyukse index onemli olabilir. Join olmadan yasanabilir sanirim ama lazim olma ihtimali de yuksek, digerleri olmasa da olur.

index ve joinsiz bir sistem yapman mümkün değil.

trigger işini çoğu zaman veritabanı yerine, backende itelerlerler. function da aynı şekild.e

ama çok derin yapılarda o ikisi de mecburi hale gelebilir.

hangi web sitesi olduguna bagli. ornegin "google" da kullanici bakis acisindan bir web sitesi.

kisaca hangi urun olursa olsun data yogun bir yazilimsa kullanilmak zorunda. yada ornegin eksiduyuruda da kullaniliyordur zorunlu olarak.

Functions: çok çok şart değil ama diğelim komplex bir grup tabloyu joinliyorsunuz ve filitreliyorsunuz. bunu her seferinde tekrar tekrar yazmak yerine functiona gömerseniz arka fonda ne olduğunu bilmek zorunda olmadan sonuç aldığınız için işiniz uzun vadade kolaylaşır.

Triggers: diyelim bir kullanıcı ve bir kullanıcının sattığı ürünler tablolarınız var, kullanıcının silinmesi durumunda tüm sattığı ürünlerinde silinmesini istiyorsunuz. bunu her seferinde 2 ayrı query ile yaparsanız unutma ihtimaliniz var, bir de bir query çakarsa diğerini geri almanız gerekir. Triggers bunu otomatik hallediyor.

Stored Procedures: Her query çalıştırdığınızda database bu query'de ne demek istemiş bu adam diye önce queryi analiz ediyor, ve bir bu queryi databasedeki index ve diğer tablolarla nasıl en efektif çalıştırırım plani yapıyor. Bunu her query çalıştığında yapmamak için önbelleğe alıyor tabii ama stored procedure yazarsanız bunu yapmak zorunda kalmıyor, hatta bazı gelişmiş veritabanları çalışan stored procedureların ne sıklıkta çalıştığını analiz ederek, sonuçları siz çalıştırmasanız bile hazır ediyor. (ama gene de ekşi duyuru'da kullanmıyorum stored procedure tembelim tembel)

Views: biraz functions gibi ama daha çok kendisini bir tablo gibi gösteriyor, mesela admin kullanıcıları viewi tanımlarsanız aslında bu kullanıcılar tablosunun bir variantı olsa bile ayrı bir tablo gibi gösteriyor kendisini.

Transactions: mesela 5 tabloyu değiştirmeniz gerekiyor (yeni kayıt ekliyorsunuz) ama bir nedenden dolayı bu 5 tablonun da hepsi düzgün çalışmazsa, hiç olmasın demenin tek yolu transactions. Transactionu başlatıp, 5 queryi tek tek çalıştırıp sonra commit ettiğiniz zaman değişiklerin hepsi bir anda veritabanına yansıtılıyor, ama revert ederseniz hiç bir şey olmamış gibi devam ediyor herşey.

Constraints: Mesela kullanıcı tablosunda kullanıcıların toplam kaç kedisi var sorusuna kullanıcının -3 kedi veya 391093 kedi girememesini sağlıyorsunuz.

Indexes: Bence tüm bu konseptlerde index konusunda "ben bunu yedim yuttum" demeniz gereken en önemli şey bu. Ekşi Duyuruda index (ve caching) olmasaydı bu site açılmazdı. Mesela 100 bin kullanıcınız var ve bunların hangisi moderatör diye bakmak istiyorsunuz, moderatormü kolonuna göre filitreleyeceksiniz diyelim. Eğer bu kolon indexli değilse database siz her query çektiğinizde 100bin kaydın hepsine bakmak zorunda kalacaktır. Ama 100bin çok gelmeyebilir, diyelim ödemeler tablonuz var ve son 2 yıldır 200 milyon ödeme aldınız. veritabanının tüm 200milyon kaydı tek tek okuması muhtemelen 10-20 saniye sürecektir. Her seferinde.

Veritabanlarında 3NF gibi konseptler de var tüm bunların dışında.

Ha veritabanında 10000 kayıt var, veritabanını 20 saniyeden daha sık sorgulamıyorum diyorsanız, o zaman bir şey yapmanıza gerek yok, ama büyüdüğü zaman hiç bir şey açılmıyorsa veya veride kaymalar ve hatalar oluyorsa nedeni bunlardır.

gereksinim ile ilgili konular, eğer düz bir blog sitesi isen pageview kısmını loglardan parse ederek de hazırlatabilirsin, trigerlar ile de yapabilirsin, X tablosundan yapılan her bir select işlemi için şu tablonun şu alanlarını +1 yap gibi, eğer çok yüksek trafik alıyorsan realtime analiz istiyorsan başka çözümlere gidersin.

bir web sitesi için kullanıcı, siparişler, sipariş dıurumu gibi bişi yapıyorsan 3 tabloyu join etmek yerine tek tek primary key kullanarak kodun içinde yapabilirsin ve gerçekten de çok hızlı olabilir, ancak patron son 3 ayda aktif kullanıcıların sipariş sayısını oranlayarak vermeni isterse o zaman joinleri kullanarak 4,5 tabloyu kullanarak bir sorgu hazırlarsın, bu sırada db'nin zorlanması web sitesinin bir iki dakika için geç açılması sorun olmayacaksa zaten bu sorgu da ayda bir belki bir daha bile çalışmayacak.

eğer sürekli çalışacak ve tasarım gereği bol joinli bir sorgun varsa bunu bir store procedure yapmak backend'e bırakmaktan daha mantıklı, zira her bir sorgu da parse et, analiz et, çalıştırma planı hazırla, vb. tüm işleri bir store procedure'u kaydettiğinde tek bir seferde yapıyor, güncellemesi, vb. daha kolay elbette sistem buna izin veriyorsa.

her şey gereksinime göre değişiyor. veri tabanını sadece veri tuttuğun ve sorguladığın yer olarak düşünmemelisin, veri tabanının gücü analiz yeteneğinden geliyor. yoksa çok daha basit veri yapıları kullanarak kendi basit db'ni yazarak çok daha yüksek performans alabilirsin ancak patron senden rapor isterse elinde patlar.