PostgreSQL 19 Öğrenci Projesinde Nasıl Değerlendirilir?

PostgreSQL 19'u öğrenci projesinde değerlendirmek için önce resmî sürüm durumunu dersin ve teslim ortamının koşullarıyla karşılaştır. Sonra istemciyi, uygulama bağlantısını ve SQL sorgularını ayrı ayrı sına; yedeğin başka bir ortamda geri yüklenebildiğini de kontrol et. Sürüm seçimini, yalnızca kendi bilgisayarında çalışmasına değil, projenin bağımsız olarak yeniden kurulabilmesine dayandır.

PostgreSQL 19 için karar hangi beş kontrolle verilir?

Öğrenci projesinde sürüm seçimi, yenilikten önce yeniden kurulabilirlik ve teslim ortamıyla uyumluluk sorusudur. Yeni bir sürümü denemek öğrenme açısından değerli olabilir; teslim edilecek projede ise değerlendiricinin aynı veritabanını kurup sorgulayabilmesi gerekir.

PostgreSQL 19 Beta 3, 13 Ağustos 2026'da duyuruldu. 24 Eylül 2026 itibarıyla PostgreSQL'in beta bilgilendirmesi bu sürümü ön sürüm olarak listeliyor. Beta aşamasında davranışlar değişebileceğinden, ders kararlı bir sürüm bekliyorsa bunu teslimin varsayılan sürümü olarak kabul etme.

1. Resmî sürüm durumu: Kullanacağın sürümün ön sürüm mü, kararlı sürüm mü olduğunu kontrol et. Dersin sürüm koşulu varsa önce onu uygula.
2. Ders, ekip ve teslim ortamı: Sunucu sürümü ile kurulumun her ekip üyesinin ve değerlendiricinin ortamında yapılabilir olup olmadığını karşılaştır.
3. İstemci, sürücü, ORM ve SQL: Bağlantı kurmayı, uygulamadan sorgu çalıştırmayı, varsa şema oluşturmayı ve projenin gerçek sorgularını ayrı ayrı dene.
4. Yedekleme ve yeniden kurulabilirlik: Yedeği almanın ötesine geç; boş bir veritabanına geri yükleyip tablo ve örnek verileri kontrol et.
5. Bağımsız teslim doğrulaması: Projeyi kendi bilgisayarındaki önceden kurulmuş dosyalara veya ayarlara dayanmadan başka bir ortamda aç.

Bu kontrollerden biri belirsizse sürüm kararını kesinleştirmeden önce küçük bir deneme kurulumu yap. Böylece sorunları projenin teslim aşamasına bırakmamış olursun.

Ders, ekip ve teslim ortamı sürümle uyumlu mu?

Önce ders yönergesindeki sunucu sürümünü ve projenin nerede değerlendirileceğini belirle. Ardından kendi yerel kurulumunu, ekip üyelerinin kurulumlarını ve teslim sistemini aynı ölçütlerle karşılaştır. PostgreSQL 19'un platform belgeleri Linux, Windows ve macOS gibi işletim sistemlerini ele alır; bu genel bilgi, seçtiğin kurulumun belirli bir bilgisayarda çalıştığını tek başına kanıtlamaz.

Bağlantı kurduktan sonra aşağıdaki kısa sorguyu çalıştırabilirsin. Bu, hangi sunucuya bağlandığını görmene ve sorgunun sonuç döndürdüğünü denetlemene yarar:

SELECT current_setting('server_version') AS sunucu_surumu,
       1 AS baglanti_testi;

Beklenen sonuç tek satırdır: baglanti_testi sütununda 1, sunucu_surumu sütununda bağlandığın sunucunun sürümü görünür. Sürümü matristeki beklentiyle karşılaştır. Bu test bağlantıyı doğrular, fakat proje tablolarının, yetkilerinin ve sorgularının çalıştığını henüz göstermez.

Bir ekip üyesinin bilgisayarında başarılı sonuç almak diğer işletim sisteminde veya değerlendirme ortamında aynı sonucu alacağını kanıtlamaz. Özellikle kurulum yöntemi, erişim izinleri ve bağlanılan sunucu farklıysa her ortamın test sonucunu ayrı kaydet; parolaları bu kayıtların içine yazma.

İstemci, sürücü, ORM ve SQL nasıl sınanır?

Bu araçlar aynı veritabanıyla çalışsa da farklı işleri sınar. Önce kullandığın istemciden hedef sunucuya bağlan ve doğru veritabanını seçtiğini denetle. Örneğin psql, sorgu gönderip sonucu görmeni sağlayan bir istemcidir; burada başarılı bağlantı, uygulamanın kullandığı sürücünün de sorunsuz çalıştığı anlamına gelmez.

İkinci testte uygulamayı kendi sürücüsüyle çalıştır. Yalnızca bağlantının açılmasına bakma: örnek veri ekle, bu veriyi bir koşulla sorgula ve dönen sonucu beklediğin değerle karşılaştır. Hata çıkarsa bağlantı ayarını, kullanıcı yetkisini ve çalıştırılan sorguyu ayrı ayrı incele. Böylece istemcide çalışan bir sorgunun uygulamada neden başarısız olduğunu daha dar bir alanda arayabilirsin.

Proje ORM kullanıyorsa boş bir veritabanında şema oluşturma veya geçiş adımlarını da dene. Tablolar oluştuğunda sütunları ve ilişkileri beklenen şemayla karşılaştır; ardından uygulamanın bu tablolara yazıp okuyabildiğini kontrol et. ORM kullanmayan projede aynı denetimi teslim edeceğin şema dosyası için yap. Araçların PostgreSQL 19 desteğini varsaymak yerine kullandığın araç sürümlerinin belgelerini ve kendi test sonuçlarını birlikte değerlendir.

Son olarak SQL'in hangi veritabanında çalışmasının beklendiğini netleştir. PostgreSQL'de büyük ve küçük harf ayrımı yapmadan eşleştirme için kullanılan ILIKE, SQL standardının değil PostgreSQL'in bir uzantısıdır. Teslim yalnız PostgreSQL üzerinde yapılacaksa bunu belirtip sorguyu hedef sunucuda sına. Başka bir veritabanında da çalışma koşulu varsa aynı sorgunun taşınacağını varsayma; hedef sistemde eşdeğer davranışı ayrıca test et.

Küçük bir SQL örneğiyle kurulum nasıl doğrulanır?

Kurulumu doğrulamak için üç şeyi ayrı ayrı kontrol et: şema oluşuyor mu, veri ekleniyor mu ve beklenen sorgu sonucu dönüyor mu? Aşağıdaki örnek boş bir veri tabanında çalışır ve PostgreSQL 19'a özgü bir özellik kullanmaz. Bu nedenle aynı doğrulama sorgusunu geri yükleme testinden sonra da çalıştırabilirsin.

CREATE TABLE projeler (
    id integer PRIMARY KEY,
    ad text NOT NULL
);

INSERT INTO projeler (id, ad)
VALUES (1, 'Deneme Projesi');

SELECT COUNT(*) AS proje_sayisi
FROM projeler;

• Şema kontrolü: CREATE TABLE komutu, id ve ad alanlarına sahip tablonun oluşturulduğunu gösterir.
• Veri kontrolü: INSERT komutu, deneme kaydının yazılabildiğini doğrular.
• Sorgu kontrolü: SELECT COUNT(*) ifadesi, eklenen kaydın sorgu sonucuna yansıdığını gösterir.

Beklenen sonuç: proje_sayisi değeri 1 olmalıdır. Geri yükleme sonrasında da aynı sorguyu değiştirmeden çalıştır. Kaynak veritabanında bu deneme kaydı bulunuyorsa sonuç 1 değilse veri aktarımı, hedef veritabanı ya da teslim edilen örnek veri dosyası ayrıca incelenmelidir.

Yedek başka bir ortamda nasıl geri yüklenip doğrulanır?

En güvenilir öğrenci projesi testi, mevcut veritabanının üzerine yazmak değil, yedeği ayrı ve boş bir hedef veritabanına yüklemektir. Aşağıdaki akışta pg_dump ile özel biçimli arşiv alınır, hedef veritabanı template0 temelinden oluşturulur ve arşiv pg_restore ile yüklenir. Komut biçimleri PostgreSQL'in resmî istemci ve yedekleme belgelerindeki kullanıma dayanır.

1. Kaynak veritabanından dump al: Kaynak veritabanına erişebilen bir ortamda pg_dump -Fc -f proje.dump proje_db komutunu çalıştır. -Fc, arşivi pg_restore ile kullanılabilecek özel biçimde oluşturur.
2. Yedek dosyasını sakla: Oluşan proje.dump dosyasını değiştirmeden koru. Geri yükleme denemesini mümkünse dosyanın bir kopyasıyla yap ve teslimde hangi dosyanın test edildiğini belirt.
3. Boş hedef veritabanı hazırla: Ayrı ortamda createdb -T template0 proje_restore komutuyla hedef veritabanını oluştur. Böylece yerel template1 değişikliklerinin tablo veya nesne çakışması oluşturma ihtimali azaltılır.
4. Arşivi geri yükle: pg_restore --exit-on-error --no-owner -d proje_restore proje.dump komutunu kullan. --exit-on-error ilk hatada işlemi durdurur. Kaynak rollerinin korunması gerekmiyorsa --no-owner seçeneği, nesne sahipliğini hedef bağlantı kullanıcısına bırakır.
5. Şema ve veriyi kontrol et: Hedefte psql -d proje_restore ile bağlan. d projeler komutuyla tablo yapısını incele, ardından ilk bölümdeki SELECT COUNT(*) AS proje_sayisi FROM projeler; sorgusunu yeniden çalıştır. Deneme kaydı teslimin parçasıysa beklenen sonuç yine 1'dir.
6. Uygulama bağlantısını test et: Uygulamanın bağlantı ayarlarını hedef veritabanına yönlendir. Uygulama içinden projeler tablosunu okuyan işlevi çalıştır. Böylece yalnızca veri tabanına giriş yapılabildiğini değil, kullanılan sürücü veya ORM katmanının da geri yüklenen şemayla çalıştığını kontrol edersin.

Bu işlemde şema, veri, bağımlılıklar ve yeniden kurulum yönergesi aynı görevi görmez.

Teslim dosyalarının rolleri nasıl ayrılmalı?

• Şema dosyası: Tabloları, alanları, kısıtları ve varsa indeksleri oluşturur. Genellikle üretim verisini içermez.
• Örnek veri dosyası: Uygulamanın çalıştığını göstermek için gerekli deneme kayıtlarını içerir. İlk bölümdeki Deneme Projesi kaydı bu amaca hizmet eder.
• Bağımlılık listesi: Kullanılan veri tabanı eklentilerini, uygulama sürücüsünü, ORM paketini, gerekli ortam değişkenlerini ve varsa rol ya da izin gereksinimlerini açıklar. Eklentilerin kurulum dosyaları dump arşivinin içinde bulunmayabilir.
• Yeniden kurulum yönergesi: Dosyaların hangi sırayla çalıştırılacağını, hedef veritabanının nasıl hazırlanacağını, beklenen doğrulama sonucunu ve uygulama bağlantı ayarlarının nereden verileceğini belirtir.

Gerçek veri tabanı parolalarını teslim dosyalarına koyma. Bunun yerine ortam değişkeni adlarını, örnek değerleri ve güvenli yapılandırma yöntemini göster. Roller, izinler veya eklentiler uygulamanın çalışması için zorunluysa bunların nasıl hazırlanacağı da yönergede açıkça yer almalıdır.

Ne zaman yeni sürüme geçmemek daha güvenlidir?

Yeni sürüme geçiş, projenin teknik olarak daha yeni görünmesinden çok tekrarlanabilir biçimde kurulup kurulamadığına göre değerlendirilmelidir. 24 Eylül 2026 itibarıyla PostgreSQL'in çevrim içi dokümantasyonunda 19, geliştirme sürümleri altında gösteriliyor. 13 Ağustos 2026 tarihli resmî duyuruda da PostgreSQL 19 Beta 3 duyurulmuştu. Bu nedenle PostgreSQL 19'u teslimin değişmez temeli gibi varsaymak yerine ders, ekip ve araç uyumunu ayrıca sınamak daha temkinlidir.

• Dersin, öğretim elemanının veya teslim sisteminin farklı bir PostgreSQL sürümünü açıkça beklediği durumlarda geçişi ertele.
• Ekipte herkesin aynı kurulumu tekrarlayamadığı, yalnızca tek bir bilgisayarda çalışan bir ortam varsa yeni sürümü teslim temeli yapma.
• Kullandığın sürücü, ORM veya veri tabanı eklentisinin uyumu gerçek proje sorgularıyla sınanmadıysa önce ayrı bir deneme ortamı kullan.
• Çalışır bir dump dosyan ve başka bir ortamda doğrulanmış geri yükleme adımın yoksa geçişi ertele. Yedek olmadan yapılan sürüm değişikliği, geri dönüş seçeneğini zayıflatır.

Yeni bir majör sürüm otomatik olarak daha yüksek performans anlamına gelmez. Performans kararını aynı veri, şema, indeksler, sorgular ve mümkün olduğunca aynı istemci koşullarıyla kontrollü karşılaştırma yaparak ver. Ölçüm sonucu olmadan yalnızca sürüm numarasına bakıp teslim ortamını değiştirme.

Teslim öncesinde hangi kontroller tamamlanmalı?

Teslim paketini göndermeden önce her madde dosya veya çalıştırılabilir bir sonuçla doğrulanmış olmalı. “Çalışıyor” demek yerine, başka bir kişinin yönergeyi izleyerek projeyi kurabilmesi ölçütünü kullan.

• Hedef ortam ve sürüm beklentisi: Kullanılacak PostgreSQL sürümü, işletim sistemi, bağlantı biçimi ve gerekli ayarlar açıkça yazılmış olmalı.
• Bağımlılıklar: Kullanılan istemci, sürücü, ORM, ek paket ve ortam değişkenleri belgelenmiş; gerekli kurulum adımları belirtilmiş olmalı.
• Şema ve örnek veri: Tabloları, ilişkileri ve kısıtları oluşturan dosyalar ile projeyi denemeye yetecek örnek kayıtlar teslim paketinde bulunmalı.
• Dump dosyası: Yedek dosyası eksiksiz olmalı ve seçilen format için uygun PostgreSQL aracıyla açılabildiği veya geri yükleme işlemine alınabildiği kontrol edilmeli.
• Temiz ortamda geri yükleme: Projenin daha önce kurulmadığı boş bir veri tabanında geri yükleme tamamlanmalı ve işlem hata vermeden sonuçlanmalı.
• Doğrulama sorgusu: Projenin temel işlevini kontrol eden sorgu çalıştırılmalı ve beklenen kayıtları, ilişkileri veya sonucu vermeli.
• Uygulama bağlantısı: Uygulama veri tabanına bağlanmalı; bağlantı ayarlarıyla birlikte temel okuma, yazma veya proje akışı sınanmalı.
• Kurulum yönergesi ve dosyalar: Kurulum sırası, çalıştırma komutları, şema dosyaları, örnek veri, dump ve uygulama dosyaları eksiksiz biçimde teslim paketinde yer almalı.

Bu liste tamamlandığında proje yalnızca kendi bilgisayarında çalışan bir çalışma olmaktan çıkar, kurulumu ve kontrolü tekrarlanabilir bir teslim hâline gelir.