Veritabanı Nasıl Yazılır, Tablo Yapısı Nasıl Kurulur?

---

Küçük bir uygulama yazarken veriyi metin dosyasında tutmak bir yere kadar gidiyor. Kayıt sayısı arttığında, aynı veriye iki yerden erişildiğinde ya da "şu tarihten sonra kaydolanları getir" gibi bir soru sorulduğunda düzenli bir yapıya ihtiyaç doğuyor.

Aşağıda veritabanının hangi parçalardan oluştuğunu, tablo tasarımının neye göre yapıldığını ve sunucuda çalışan bir sistemle tek dosyalık bir motorun nerede ayrıştığını iki projenin kendi belgelerine dayanarak bulacaksınız.

Tablo, satır, sütun​

PostgreSQL'in kavramlar bölümü yapıyı üç kelimeyle kuruyor. Belgeye göre PostgreSQL, veriyi ilişkiler içinde yöneten bir ilişkisel veritabanı yönetim sistemi ve "ilişki" matematiksel bir terim olarak tabloyu karşılıyor.

Tanımlar net: her tablo adlandırılmış satırlardan oluşan bir koleksiyon, bir tablonun her satırı aynı adlandırılmış sütun kümesine sahip ve her sütun belirli bir veri tipinde.

• Tablo: Tek bir varlığı tutar — kullanıcılar, siparişler, ürünler gibi.
• Sütun: O varlığın bir özelliğini ve o özelliğin veri tipini tanımlar.
• Satır: Varlığın tek bir örneğidir; bütün sütunlara karşılık gelen değerleri taşır.

Belgenin bir uyarısı tasarım açısından kritik: SQL, satırların tablo içindeki sırasını garanti etmiyor. Belirli bir sıra isteniyorsa sorguda açıkça belirtilmesi gerekiyor.

Tablolar nerede duruyor?​

Aynı bölüm hiyerarşiyi de tarif ediyor: tablolar veritabanlarında gruplanıyor ve tek bir sunucu örneğinin yönettiği veritabanı topluluğu bir küme oluşturuyor.

Bu üç katman, "veritabanı yazmak" denen işin aslında ne olduğunu gösteriyor. Yazdığınız şey veri değil, verinin duracağı şema: hangi tablo, hangi sütunlar, hangi tipler.

Tasarıma başlarken' Alıntı:

Önce tabloları değil soruları listeleyin. "Hangi kullanıcı hangi siparişi verdi", "bu ay kaç kayıt geldi" gibi sorular, hangi tabloya hangi sütunun gerektiğini kendiliğinden söyler.

Genişletmek için tıkla ...

Sunucu mu, tek dosya mı?​

Her proje sunucuda çalışan bir veritabanı gerektirmiyor. SQLite'ın tanıtım sayfası kendini kendine yeterli, sunucusuz, sıfır yapılandırmalı ve işlemsel bir SQL veritabanı motoru uygulayan işlem içi bir kütüphane olarak tanımlıyor.

Belgeye göre SQLite'ın ayrı bir sunucu süreci yok; doğrudan sıradan disk dosyalarına okuyup yazıyor. Birden çok tablo, indeks, tetikleyici ve görünüm içeren eksiksiz bir SQL veritabanı tek bir disk dosyasında duruyor.

Aynı sayfa kullanım felsefesini tek cümleyle özetliyor: SQLite'ı Oracle'ın değil, `fopen()` çağrısının yerine geçen bir şey olarak düşünün. Yani karşılaştırma büyük veritabanı sunucularıyla değil, dosyaya elle yazmakla yapılıyor.

Veri kaybı riski nerede başlıyor?​

Dosyaya elle yazmakla veritabanı kullanmak arasındaki en somut fark, yarım kalan işlemlerde ortaya çıkıyor. SQLite'ın belgesi işlemlerin sistem çökmesi ya da elektrik kesintisiyle kesilse bile ACID özelliklerini koruduğunu belirtiyor.

Pratik karşılığı şu: bir kayıt ya tamamen yazılıyor ya da hiç yazılmıyor; yarı yazılmış bir satırla uyanmıyorsunuz. Kendi dosya biçiminizi yazdığınızda bu garantiyi de kendiniz kurmak zorunda kalırsınız.

Ölçek ve sınırlar​

Tek dosyalık bir motorun sınırlarını bilmek, doğru aracı seçmeyi kolaylaştırıyor. SQLite'ın sayfası veritabanı boyutunun 281 terabayta, satır boyutunun 1 gigabayta kadar çıkabildiğini ve kütüphanenin tüm özellikleriyle 900 KiB'ın altında kaldığını belirtiyor.

Sunucu tarafındaki gerekçe ise eşzamanlılık: aynı veriye çok sayıda istemcinin aynı anda yazdığı bir uygulamada süreçler arası koordinasyonu bir sunucu üstleniyor. Tek kullanıcılı bir masaüstü aracında ya da tek süreçli bir işte bu koordinasyona ihtiyaç duyulmadığı için dosya tabanlı motor yeterli kalıyor.

Kurduktan sonra ne gelir?​

Yapı ayakta durduğunda sıra iki işe geliyor: yedek ve performans. Yedeğin gerçekten geri yüklenip yüklenmediğini sınamayı veritabanı yedeklemesini ele aldığımız yazıda anlatmıştık.

Sorgular yavaşladığında nereye bakılacağını yavaş sorgu incelemesini anlattığımız yazıda ele aldık. Sunucu hiç açılmıyorsa sorun veri tarafında olmayabilir; bu durumda beklenmedik kapanma hatasını incelediğimiz yazıya bakabilirsiniz.

Sık Sorulan Sorular​

Veritabanı nasıl yazılır?
Önce hangi soruların yanıtlanacağı belirlenir, sonra her varlık için bir tablo ve o varlığın özellikleri için sütunlar tanımlanır. PostgreSQL'in belgesine göre her tablo adlandırılmış satırlardan oluşur ve her sütun belirli bir veri tipindedir.

Tablo ile veritabanı arasındaki fark ne?
Tablolar veritabanlarında gruplanır; tek bir sunucu örneğinin yönettiği veritabanı topluluğu ise bir küme oluşturur.

Her projede veritabanı sunucusu şart mı?
Hayır. SQLite'ın belgesi kendisini sunucusuz, sıfır yapılandırmalı bir motor olarak tanımlıyor; ayrı bir sunucu süreci olmadan doğrudan disk dosyalarına yazıyor.

Tek dosyada veritabanı güvenli mi?
SQLite'ın sayfasına göre işlemler, sistem çökmesi veya elektrik kesintisiyle kesilse bile ACID özelliklerini koruyor.

Satırların sırası garanti mi?
Hayır. PostgreSQL'in belgesi SQL'in satır sırasını garanti etmediğini, sıralamanın açıkça istenmesi gerektiğini belirtiyor.

Özetle​

Veritabanı tasarımı, veriyi tablolara bölüp her sütuna bir tip vermekle başlıyor; yazdığınız asıl şey veri değil şema. Sunucuda çalışan bir sistem eşzamanlı erişimi yönetiyor, tek dosyalık bir motor ise yapılandırma yükü olmadan aynı SQL yapısını sunuyor. Seçim, veriye kaç yerden aynı anda yazılacağına bakıyor.

Şu an veriyi dosyada tutan bir işiniz var mı, tabloya taşımak ne kazandırırdı?

Güncelleme: 26 Ağustos 2026.

---