Çoğu işletme sahibi veritabanını bir depo sanır: kurulur, dolar, unutulur. Oysa bir e-pin operasyonunda veritabanı deposu değil, kasasıdır; aynı kodun iki müşteriye satılıp satılmayacağına, iade talebinde kimin haklı olduğuna, ay sonu raporunun doğru mu yanlış mı olduğuna karar veren yer tam olarak orasıdır. Ve bu kararların büyük kısmı, sen henüz tek ürün girmemişken, kurulum sihirbazının ilk ekranında kilitlenir.
İlk şemanın bedeli hemen çıkmaz. İlk ay her şey yolunda görünür. Bedeli, kampanya gecesi aynı saniyede gelen kırk siparişte, Türkçe karakterli oyun adlarının bozuk görünmesinde, bayi bakiyesinin bir kuruş kaymasında ve altı ay sonra rapor sorgusunun kırk saniye sürmesinde ödersin. Bu yazı, bir e-pin satış scripti kurarken veritabanı tarafında verilmesi gereken kararları, sonradan geri dönüşü olmayanlardan başlayarak sıralıyor.
Karakter seti kararı neden geri dönüşü en zor adım?
Veritabanını kurarken karakter setini varsayılana bırakmak, yıllar sonra düzeltilecek bir borç almaktır. Eski utf8 seti dört baytlık karakterleri taşımaz; yani müşteri adında emoji, oyun adında bazı özel simgeler ya da destek mesajında kullanılan bir işaret kaydı kesintiye uğratır. Daha kötüsü, karşılaştırma (collation) ayarı yanlışsa "Ismail" ile "İsmail" farklı iki kullanıcı gibi davranır ve sen iki ayrı bakiyeyle uğraşırsın.
Doğru kurulum utf8mb4 ve Türkçe metinlerde beklenen davranışı veren bir karşılaştırma ayarıdır. Bu kararı kurulumdan sonra değiştirmek teknik olarak mümkündür ama tablolar yüz binlerce satıra ulaştığında dönüştürme işlemi paneli saatlerce kilitleyebilir. Bir dijital ürün satış yazılımı kurarken ilk ekranda bu tek satırı doğru seçmek, altı ay sonraki bakım gecesini tamamen ortadan kaldırır.
| Şema kararı | Yanlış seçimin görünen belirtisi | Sonradan değiştirme maliyeti | Doğru varsayılan |
|---|---|---|---|
| Karakter seti | Bozuk Türkçe, kaydolmayan mesajlar | Yüksek: tablo dönüşümü, kilitlenme | utf8mb4 |
| Tutar alanı tipi | Bakiyede kuruş kayması | Orta: veri düzeltmesi gerekir | Ondalıklı sabit tip, kayan nokta değil |
| Tablo motoru | Yarım kalan sipariş, tutarsız stok | Orta: motor değişimi | İşlem destekli motor (InnoDB) |
| Birincil anahtar | Tahmin edilebilir sipariş adresleri | Yüksek: tüm ilişkiler etkilenir | Artan kimlik + herkese açık ayrı belirteç |
| Zaman damgası | Saat farkı, yanlış günlük rapor | Düşük ama can sıkıcı | Tek tip, tek saat dilimi standardı |
| Silme politikası | Kaybolan satış geçmişi | Onarılamaz | Yumuşak silme (kayıt işaretlenir, silinmez) |
İlk şemada hangi tablolar gerçekten zorunlu?
Kurulumu karmaşıklaştırmanın en kolay yolu, daha ilk gün otuz tablo tasarlamaktır. Gerçekte bir e-pin operasyonunun çekirdeği yedi tablodan ibarettir: kullanıcılar, ürünler, stok kalemleri, siparişler, sipariş satırları, cüzdan hareketleri ve olay kaydı. Geri kalan her şey bu yedisinin üzerine sonradan eklenebilir. Çekirdeği sade tutmanın faydası şudur: her yeni özellik geldiğinde şemayı yeniden düşünmek yerine yalnızca ilişkiyi kurarsın.
Bu tabloların içinde en yanlış tasarlanan, neredeyse istisnasız, stok kalemleri tablosudur. Çoğu kurulum stoğu ürün tablosunda sayı olarak tutar: "elimizde 120 adet var". Bu yaklaşım e-pinde çöker, çünkü satılan şey sayı değil, benzersiz bir kodun kendisidir. Her kodun ayrı satır olduğu, durumu (beklemede, ayrılmış, teslim edildi, iptal) ve hangi siparişe bağlandığı tutulan bir tablo, hem çift satışı hem de "ben kodu aldım mı almadım mı" tartışmasını bitirir.
Aynı kodun iki kişiye satılmasını ne engelliyor?
Kimse kod dosyasını elle karıştırmıyor; çift satış neredeyse her zaman zamanlama yüzünden olur. İki sipariş aynı anda gelir, ikisi de aynı sıradaki ilk boş kodu okur, ikisi de "bu kod boş" sonucunu alır ve ikisi de aynı kodu teslim eder. Bunu engelleyen şey hızlı sunucu değil, veritabanı düzeyinde uygulanan kilit ve işlem (transaction) disiplinidir: kod önce ayrılır, ayırma başarılıysa sipariş ilerler, başarısızsa sistem bir sonraki koda geçer.
Bu davranışı kodda "kontrol et, sonra yaz" şeklinde yazmak yetmez; iki adımın arasına sığan mikrosaniye, işin kayıp noktasıdır. İşlem destekli bir tablo motoru, kod satırında benzersizlik kısıtı ve ayırma adımının tek atomik güncelleme olarak yazılması, üçü birlikte sorunu tamamen kapatır. İyi kurgulanmış bir epin yazılım altyapısında bu mantık senin yazmana gerek kalmadan hazır gelir; kötü kurgulanmışta ise ilk büyük kampanyada faturayı sen ödersin.
Veritabanı kaynaklı panel sorunlarının dağılımı
- Eksik indeks ve yavaş sorgu 35%
- Yanlış stok modeli ve çift satış 30%
- Karakter seti ve tutar tipi hataları 25%
- Yedekleme ve geri dönüş eksikliği 10%
Panel altı ay sonra neden yavaşlıyor?
Çünkü ilk gün on satırla test edilen sorgular, iki yüz bin satırda tamamen farklı davranır. Sipariş listesini tarihe göre sıralayan, kullanıcıya göre filtreleyen, duruma göre sayan her sorgu; ilgili kolonlarda indeks yoksa tabloyu baştan sona tarar. Donanım büyütmek bunu bir süre saklar, çözmez. Doğru hamle, ilk şemayı kurarken hangi kolonların filtreleme ve sıralamada kullanılacağını öngörüp indeksleri o gün koymaktır.
Pratik kural: her yabancı anahtar indekslenir, her durum kolonu indekslenir, tarih kolonları sıralama için indekslenir ve çok kullanılan filtre çiftleri için bileşik indeks açılır. Buna karşılık her kolona indeks atmak da yazma hızını düşürür; e-pin operasyonunda stok tablosuna saniyede yüzlerce yazma gelebileceği için bu denge önemlidir. Ölçmeden indeks eklemek yerine, panelin yavaşlayan ekranını tespit edip o ekranın sorgusuna bakmak en verimli yoldur.
Kayan nokta tipleri 0,1 gibi değerleri birebir saklamaz. Bin işlem sonra bayi bakiyesi gerçekten bir kuruş kayar ve o kuruş, bayinle aranı bozan tek şey olur. Tutarları ondalıklı sabit tip ya da kuruş cinsinden tam sayı olarak tut.
Yedekleme ve geri dönüş planı şemanın parçası mı?
Evet, çünkü yedeği olmayan şema yarım şemadır. E-pin işinde yedeklemenin özel bir yönü var: kaybettiğin veri sadece kayıt değil, satılabilir stoktur. Bir gün öncesine dönmek, o gün teslim edilmiş kodları tekrar "boşta" göstermek anlamına gelir ve aynı kodu ikinci kez satarsın. Bu yüzden geri dönüş planı, yedeği yüklemekle bitmez; hangi siparişlerin yedek anından sonra oluştuğunu bulup stok durumlarını mutabık kılmayı da içermelidir.
Bunu mümkün kılan tek şey olay kaydı (audit log) tablosudur. Her stok durumu değişiminin kim tarafından, ne zaman ve hangi sipariş yüzünden yapıldığını yazan bir tablo tutuyorsan, geri dönüşten sonra aradaki farkı yeniden oynatabilirsin. Tutmuyorsan, elinde sadece tahmin kalır. Özellikler listesinde olay kaydını süs gibi görmemenin sebebi tam olarak budur.
Kurulumu bitirmeden önce hangi listeyi kapatmalısın?
Aşağıdaki liste, ilk şemayı devreye almadan önce kapatılması gereken maddeleri içeriyor. Her satır, sonradan düzeltmesi düzgün kurmaktan en az on kat pahalı olan bir kalemdir. Yeni kurulumda bu tabloyu yazdırıp tek tek işaretlemek, panelin ilk yılını sorunsuz geçirmesinin en ucuz yoludur.
| Kontrol maddesi | Neden kritik | Doğrulama yöntemi | Durum |
|---|---|---|---|
| utf8mb4 + doğru karşılaştırma | Türkçe ve özel karakter kaybı | Türkçe adlı test kaydı ekle ve oku | Zorunlu |
| İşlem destekli motor | Yarım kalan sipariş riski | Tablo motorunu listele | Zorunlu |
| Kod satırında benzersizlik kısıtı | Çift satış engeli | Aynı kodu iki kez eklemeyi dene | Zorunlu |
| Eşzamanlı sipariş testi | Kilit mantığının kanıtı | Aynı ürüne paralel iki sipariş | Zorunlu |
| Tutar alanı sabit ondalık | Bakiye kayması | Kolon tipini kontrol et | Zorunlu |
| Temel indeksler | Panel yavaşlığı | Sipariş listesi sorgu planı | Zorunlu |
| Olay kaydı tablosu | Geri dönüş ve anlaşmazlık çözümü | Bir stok değişimi sonrası kayıt var mı | Zorunlu |
| Otomatik yedek + geri yükleme provası | Yedeğin işe yaradığının kanıtı | Boş bir ortama gerçekten yükle | Zorunlu |
Şemayı doğru kurulmuş halde devral
Stok kalemi modeli, kilit disiplini, olay kaydı ve indeksler hazır gelen bir kurulumla başla; ilk kampanya gecesini rahat geçir.
Stok sayısını ürün tablosunda tutmak neden yanlış?
Çünkü e-pinde satılan şey adet değil, benzersiz kodun kendisidir. Her kodun ayrı satır olduğu bir tablo olmadan hangi kodun kime gittiğini kanıtlayamaz, çift satışı da güvenilir biçimde engelleyemezsin.
Kurulumdan sonra karakter setini değiştirebilir miyim?
Teknik olarak evet, ancak tablolar büyüdükçe dönüştürme işlemi uzun sürer ve paneli kilitleyebilir. Doğru seçim kurulum ekranında utf8mb4 işaretlemek ve konuyu bir daha açmamaktır.
Kaç indeks koymak doğru?
Yabancı anahtarlar, durum kolonları ve sıralama yapılan tarih kolonları indekslenir. Fazlası yazma hızını düşürür; bu yüzden indeks eklemeyi tahminle değil, yavaşlayan ekranın sorgusunu inceleyerek yap.
Olay kaydı tablosu veritabanını çok büyütür mü?
Büyütür ama bu maliyet, tek bir anlaşmazlıkta veya geri yükleme sonrası mutabakatta kendini fazlasıyla amorti eder. Eski kayıtları aylık olarak arşiv tablosuna taşıyarak boyutu yönetilebilir tutabilirsin.
İlk şema, işletmenin sonraki üç yılda ne kadar rahat büyüyeceğini belirleyen tek dosyadır; kurulum ekranında geçirdiğin on dakika, ileride haftalarca süren onarımın yerine geçer. Doğru kurulmuş bir stok kalemi modelinin, kilit mantığının ve olay kaydının panelde nasıl göründüğünü merak ediyorsan canlı demo içinde bir ürüne kod yükleyip test siparişi geçirmeyi dene; şemanın kalitesi ilk siparişte kendini belli eder.