DBAtlas · Veritabanı operasyon atlası

Karar: Doğru veri tipini seç

Veri tipi seçimi, sonradan düzeltmesi en pahalı kararlardan biridir: yanlış tip yanlış sonuç (ör. para için float), boşa yer ve yavaş sorgu üretir. Bu ağaç; sayısal, metin, tarih/saat, anahtar (PK), yarı-yapılı (JSON) ve kategori (ENUM) alanları için doğru tipe yönlendirir ve para/karakter kümesi gibi klasik tuzakları vurgular.

Hangi tür veriyi saklıyorsun?

Doğru tip, verinin doğasına göre belirlenir. Saklayacağın alan hangi kategoriye giriyor: sayı mı, metin mi, tarih/saat mi, tablonun primary key'i mı, esnek/yarı-yapılı (JSON) veri mi, yoksa sınırlı bir kategori kümesi mi?

  • Sayısal değer (miktar, para, ölçüm, sayaç)
  • Metin (isim, açıklama, kod)
  • Tarih ve/veya saat
  • Primary key (PK) tasarlıyorum
  • Esnek/iç içe/değişken alanlar (yarı-yapılı veri)
  • Sınırlı, bilinen kategori kümesi (durum, tip, öncelik)

Sayı tam sayı mı, ondalık mı — ve para mı?

Sayısallarda en kritik ayrım kesinliktir. Değer tam sayı mı (adet, kimlik, sayaç), yoksa ondalık mı? Ondalıksa bu bir PARA/finansal tutar mı? Para ve kesinlik gerektiren her yerde ikili kayan nokta (FLOAT/DOUBLE) yuvarlama hatası ürettiği için kesinlikle kullanılmaz.

  • Tam sayı (adet, sayaç, id)
  • Para veya kesin ondalık (fiyat, bakiye, oran)

Öneri: Tam sayı (SMALLINT / INT / BIGINT)

Tam sayılar için gereken aralığa göre en küçük yeterli tipi seç. Gereksiz büyük tip yer ve index boyutu israfıdır; ama sayaç/PK gibi büyüyebilen alanlarda taşmayı (overflow) önlemek için yeterli genişlik şarttır.

Öneri: NUMERIC / DECIMAL — para için ASLA FLOAT

Para ve kesin ondalıklar için sabit-nokta (exact) NUMERIC/DECIMAL kullan. FLOAT/DOUBLE ikili kayan noktadır ve 0.1 gibi değerleri tam saklayamaz; toplama/çarpmada kuruş kayması, yanlış bakiye ve denetim sorunları üretir.

Öneri: Metin — VARCHAR vs TEXT vs CHAR

Metinde değişken uzunluklu için VARCHAR/TEXT, gerçekten sabit uzunluk için CHAR kullanılır. Modern motorlarda VARCHAR ile TEXT arasında depolama farkı çoğunlukla önemsizdir; asıl karar anlamsal sınır (uzunluk constraint'i) koyup koymamandır.

Öneri: Tarih/saat — zaman dilimli TIMESTAMP

Bir anı (olay zamanı) saklıyorsan zaman dilimi bilincine sahip tipi seç. Zaman dilimsiz saklamak, farklı bölge/yaz saati durumlarında yanlış hesaplama ve karşılaştırmaya yol açar.

Öneri: Primary key — BIGINT vs UUID

PK seçiminde iki ana yol vardır: artan sayısal (BIGINT identity/sequence) veya UUID. Sayısal PK küçük ve index dostu ama tahmin edilebilir ve merkezi üretim gerektirir; UUID dağıtık üretilebilir ama daha büyük ve rastgele sırası index'i olumsuz etkileyebilir.

Öneri: JSON / JSONB — ölçülü kullan

Şeması esnek, iç içe veya seyrek alanlar için JSON tipi güçlüdür; ama ilişkisel disiplin (constraint, index, tip güvenliği) kaybolabilir. Kural: sabit ve sık sorgulanan alanları normal kolonlara çıkar, gerçekten değişken kısmı JSON'da tut.

Öneri: ENUM vs lookup (referans) tablo

Sınırlı kategori kümeleri için iki yol vardır: motorun ENUM tipi ya da bir lookup tablosu + foreign key. ENUM kompakt ve basittir ama değer eklemek şema değişikliği gerektirir; lookup tablo esnektir ve ek nitelik (açıklama, aktiflik, sıra) taşıyabilir.

DBAtlas'ta aç →