SQL View Nasıl Oluşturulur ve Ne Zaman Kullanılır?
SQL view, bir veya birden fazla tablodan gelen verileri belirli bir SELECT sorgusuyla birleştirip sanal bir tablo gibi sunan veritabanı nesnesidir. View oluşturmak için CREATE VIEW view_adı AS SELECT ... sözdizimi kullanılır ve bu view, karmaşık sorguları tekrar tekrar yazmak zorunda kalmadan basit bir tablo gibi sorgulanabilir. View, tekrarlanan raporlama sorgularını sadeleştirmek, hassas sütunları gizlemek veya veriye mantıksal bir katman eklemek istendiğinde kullanılır.
Bu makalede view'in ne olduğunu, tablo ile farkını, adım adım nasıl oluşturulacağını ve hangi durumlarda view kullanmanın anlamlı olduğunu ele alacağız.
View Nedir?
View, aslında saklanmış bir SELECT sorgusudur. Veritabanı içinde bir view oluşturduğunuzda, veri fiziksel olarak kopyalanmaz veya yeni bir tabloya yazılmaz; sadece sorgunun tanımı kaydedilir. View'e her erişildiğinde, arka planda bu SELECT sorgusu yeniden çalıştırılır ve güncel veri döndürülür.
Bu yapı, view'i bir "sanal tablo" haline getirir. Kullanıcı veya uygulama tarafından bakıldığında normal bir tablo gibi görünür; SELECT ile sorgulanabilir, bazı durumlarda filtrelenebilir, JOIN işlemlerine dahil edilebilir. Ancak arka planda gerçek bir veri deposu yoktur, sadece tabloların üzerine kurulmuş bir sorgu mantığı vardır.
View'in en pratik faydası, karmaşık ve sık kullanılan sorguları tek bir isim altında toplamaktır. Örneğin beş tabloyu birleştiren bir raporlama sorgusu her seferinde yeniden yazılmak yerine, bir view olarak tanımlanıp basitçe SELECT * FROM rapor_view şeklinde çağrılabilir.
View ile Tablo Arasındaki Fark
Kısaca söylemek gerekirse: tablo veriyi diskte fiziksel olarak saklar, view ise veriyi saklamaz; sadece bir sorgunun tanımını saklar ve her çağrıldığında bu sorguyu çalıştırır.
Bu farkı tek satır SQL ile de göstermek mümkün:
-- Tablo: veri fiziksel olarak burada durur
CREATE TABLE ogrenciler (id INT, ad VARCHAR(50));
-- View: veri saklamaz, sadece sorguyu saklar
CREATE VIEW aktif_ogrenciler AS SELECT id, ad FROM ogrenciler WHERE durum = 'aktif';Bu ayrım, performans ve güncelleme davranışı açısından önemlidir. Tabloya veri eklendiğinde disk alanı kullanılır; view'e "veri eklemek" ise mümkün değildir, çünkü view'in kendi verisi yoktur, sadece bağlı olduğu tablolardaki veriyi yansıtır. Tablodaki veri değiştiğinde view'den okunan sonuç da otomatik olarak güncellenir, çünkü view her sorgulandığında altındaki SELECT yeniden çalışır.
CREATE VIEW ile Adım Adım Oluşturma
Örnek olarak ogrenciler ve notlar adında iki tablo düşünelim. ogrenciler tablosunda öğrenci id ve adı, notlar tablosunda ise öğrenciye ait ders ve puan bilgisi bulunsun. Bu iki tablodan öğrenci adı ve ortalama notunu döndüren bir view oluşturalım.
1. Adım: İhtiyacınız olan sonucu önce normal bir SELECT ile test edin:
SELECT o.ad, AVG(n.puan) AS ortalama_not
FROM ogrenciler o
JOIN notlar n ON o.id = n.ogrenci_id
GROUP BY o.ad;2. Adım: Sorgu doğru sonucu verdiğinde, başına CREATE VIEW ekleyerek kalıcı hale getirin:
CREATE VIEW ogrenci_ortalamalari AS
SELECT o.ad, AVG(n.puan) AS ortalama_not
FROM ogrenciler o
JOIN notlar n ON o.id = n.ogrenci_id
GROUP BY o.ad;3. Adım: View'i normal bir tablo gibi sorgulayın:
SELECT * FROM ogrenci_ortalamalari WHERE ortalama_not >= 70;Bu üç adım, herhangi bir view oluşturma sürecinin temelini oluşturur: önce sorguyu yaz ve test et, sonra CREATE VIEW ile sabitle, ardından view'i sıradan bir tablo gibi kullan.
Doğrudan Sorgu mu, View mi? Karşılaştırma
Aynı raporu iki farklı şekilde çalıştırabilirsiniz: her seferinde uzun bir SQL sorgusu yazarak veya bu sorguyu bir view'e sarıp tek satırla çağırarak. Aradaki fark sadece yazım kolaylığından ibaret değil, birkaç pratik noktada kendini gösterir.
Tekrar kullanılabilirlik açısından view net bir avantaj sağlar. Beş farklı rapor ekranı aynı JOIN mantığını kullanıyorsa, bu mantığı bir view'de tanımlayıp her yerden SELECT * FROM view_adi ile çağırmak, aynı sorguyu beş kez kopyalayıp yapıştırmaktan daha güvenlidir. Mantıkta bir değişiklik gerektiğinde tek yeri güncellersiniz.
Performans tarafında ise view başlı başına bir hızlandırma aracı değildir. Standart bir view, arka planda yine aynı sorguyu çalıştırır; sonuçları önceden hesaplayıp saklamaz. Dolayısıyla "view kullanınca sorgu hızlanır" beklentisi doğru değildir. Bazı veritabanı ürünlerinde sonuçları fiziksel olarak saklayan materialized view (veya benzer) seçenekler bulunur, ancak bunlar ayrı bir konu ve ayrı bir bakım yükü getirir.
Okunabilirlik açısından view, karmaşık sorguları sadeleştirir. Uygulama kodunda veya raporlama aracında FROM aylik_satis_ozeti görmek, üç sayfalık bir JOIN zincirini görmekten çok daha anlaşılırdır. Doğrudan sorgu ise esnekliği elinizde tutar; her çalıştırmada filtreyi, sıralamayı veya seçilen kolonları değiştirebilirsiniz. View de parametre almadığı için (temel SQL view'lerinde) bu esnekliği WHERE ile view üzerine ek filtre koyarak sağlarsınız.
View Seçme Kontrol Listesi
View kullanmaya karar vermeden önce şu kısa listeyi gözden geçirmek işe yarar:
- Aynı sorgu mantığı üç veya daha fazla yerde tekrar ediyorsa, view'e almak mantıklıdır.
- Sorgu birden fazla tabloyu birleştiriyor ve bu birleşim mantığı sık değişmiyorsa, view iyi bir soyutlama katmanı olur.
- Belirli kullanıcı gruplarına tablonun sadece bir kısmını (belirli kolonlar veya satırlar) göstermek istiyorsanız, view bunun için uygun bir araçtır.
- Sorgu tek bir yerde, tek bir seferlik ihtiyaç için kullanılıyorsa view eklemek gereksiz bir katman olur; doğrudan sorgu yeterlidir.
- Sorgunun sık sık farklı parametrelerle (farklı tarih aralığı, farklı filtre) çalışması gerekiyorsa ve veritabanınız parametreli view desteklemiyorsa, bir fonksiyon veya saklı yordam daha uygun olabilir.
- Performans darboğazı yaşıyorsanız ve amaç sonuçları önceden hesaplayıp saklamaksa, standart view yerine materialized view veya ayrı bir özet tablo değerlendirilmelidir.
Güncelleme, Güvenlik ve Bakım Sınırları
View üzerinden veri güncellemek her zaman mümkün değildir. Basit, tek tablodan oluşan ve JOIN, GROUP BY, DISTINCT gibi ifadeler içermeyen view'lerde UPDATE/INSERT genellikle desteklenir. Ancak birden fazla tabloyu birleştiren veya agregasyon içeren view'lerde bu işlemler kısıtlanır ya da tamamen engellenir. Bu destek ve kısıtlar kullanılan veri tabanı ürününe ve view tanımına göre değişir; UPDATE veya INSERT işlemlerinden önce ilgili sistemin belgelerindeki kurallar kontrol edilmelidir.
Güvenlik açısından view'ler faydalı bir katman sunar: kullanıcıya doğrudan tabloya erişim vermek yerine, sadece görmesi gereken kolonları içeren bir view üzerinden yetki tanımlayabilirsiniz. Bu, hassas kolonları (örneğin maaş bilgisi) gizlemek için pratik bir yöntemdir.
Bakım tarafında ise view'lerin kendine ait bir riski var: alttaki tablo yapısı değiştiğinde (kolon adı, tip değişikliği gibi) view bozulabilir ve bu hata çoğu zaman view çalıştırılana kadar fark edilmez. Ayrıca iç içe geçmiş view'ler (bir view'in başka bir view'i çağırması) zamanla takip edilmesi zor bir bağımlılık zinciri oluşturabilir.
Sık Yapılan Hatalar
View kullanırken en sık düşülen tuzaklardan biri, view'ın her veritabanı sisteminde aynı şekilde davrandığını sanmaktır. PostgreSQL, MySQL, SQL Server gibi sistemler view'ları farklı şekillerde optimize eder; bazıları view sorgusunu her çalıştırmada yeniden yorumlarken bazıları belirli koşullarda önceden hesaplanmış sonuçlardan yararlanabilir. Bir sistemde sorunsuz çalışan bir view, başka bir sistemde ciddi performans farkı gösterebilir. Bu yüzden view'ı taşınabilir bir standart gibi değil, kullanılan sisteme özgü bir yapı gibi ele almak gerekir.
İkinci yaygın hata, view'ı bir performans çözümü gibi görmektir. View, temelde bir sorguyu saklayan bir tanımdır; verinin kendisini fiziksel olarak saklamaz (materialized view istisnası dışında). Dolayısıyla altındaki sorgu yavaşsa, view de o kadar yavaş çalışır. Karmaşık join'ler veya büyük veri kümeleri üzerinde kurulan bir view, sorunu çözmek yerine sadece gizler. Gerçek performans ihtiyacı varsa index optimizasyonu, sorgu yeniden yazımı veya materialized view gibi seçenekler değerlendirilmelidir.
Bunlara ek olarak, view'lar üzerine view kurarak (nested view) katmanları çoğaltmak, hangi verinin nereden geldiğini takip etmeyi zorlaştırır ve hata ayıklamayı karmaşıklaştırır. Basitlik ve okunabilirlik, view tasarımında performanstan önce gelen bir önceliktir.
Sık Sorulan Sorular
View'ı silmek tablodaki veriyi de siler mi?
Hayır. View sadece bir sorgu tanımıdır, veriyi fiziksel olarak tutmaz. DROP VIEW komutu view tanımını kaldırır, altında yer alan tablolardaki veriler etkilenmez.
View'lar index içerebilir mi?
Standart view'lar kendi index'ine sahip olmaz, altındaki tabloların index'lerinden yararlanır. Bazı sistemlerde bulunan indexed veya materialized view'lar ise sonucu fiziksel olarak saklayarak index eklemeye izin verir.
Bir view içinde başka bir view kullanılabilir mi?
Evet, teknik olarak mümkündür ama önerilmez. İç içe view'lar sorgu planını karmaşıklaştırır ve hata ayıklamayı zorlaştırır, bu yüzden gerekmedikçe tek katmanlı view yapısı tercih edilmelidir.
View'daki bir sütunun adını değiştirmek orijinal tabloyu etkiler mi?
Hayır. View içinde alias ile verilen sütun adları sadece o view'a özgüdür, kaynak tablodaki sütun adları değişmez.
View, doğru yerde ve doğru amaçla kullanıldığında sorguları sadeleştiren, güvenliği katmanlandıran ve tekrarı azaltan pratik bir araçtır; ancak her sorunun çözümü olmadığını bilerek, sistemin gerçek ihtiyacına göre değerlendirilmesi en sağlıklı yaklaşımdır.
