ETA’da SQL Tabanlı Sürüme Geçmek: Ne Zaman Gerekir?

ETA’nın ürün ailesinde verinin nerede ve nasıl tutulduğu sürüme göre değişir. Eski nesil kurulumlarda veri dosya tabanlı tutulur; SQL tabanlı sürümlerde ise bir veri tabanı sunucusu üzerinde çalışır.

Kullanıcı açısından ekranlar büyük ölçüde benzer görünür — fark ekranda değil, verinin arka planda nasıl korunduğundadır. Bu yüzden karar “daha yeni sürüm daha iyidir” gibi genel bir gerekçeyle değil, somut belirtilerle verilmelidir.

Dosya tabanlı bir kurulumda çalışıyorsanız ve aşağıdakilerden biri yaşanıyorsa, SQL tabanlı sürüm gündeme alınmalıdır:

• Program sık sık donuyor ya da kayıt sırasında “dosya kullanımda” türü hatalar veriyor
• Elektrik ya da ağ kesintisinden sonra veri onarımı gerekiyor
• Aynı anda giriş yapan kullanıcı sayısı arttıkça belirgin yavaşlama oluyor
• Yıllar biriktikçe dosya boyutu büyüdü ve raporlar uzun sürüyor
• Yedekten dönme ihtiyacı doğduğunda saatler süren bir işle karşılaşılıyor

Bunların hiçbiri yaşanmıyorsa, tek başına “sürüm eski” gerekçesiyle geçiş yapmak acele bir karardır. Çalışan bir kurulumu değiştirmenin kendi riski vardır.

Eşzamanlı erişim

Veri tabanı sunucusu, aynı kayda aynı anda erişen kullanıcıları yönetir. Dosya tabanlı yapıda bu yönetim daha kırılgandır; kullanıcı sayısı arttıkça kilitlenme ve bozulma riski büyür.

Veri bütünlüğü

İşlem yarıda kaldığında (elektrik kesintisi, ağ kopması) veri tabanı işlemi geri alır. Dosya tabanlı yapıda yarım kalmış yazma işlemi bozuk kayıt bırakabilir; onarım aracı çalıştırmak gerekir.

Yedekleme

Veri tabanı yedeklemesi, program açıkken ve kullanıcılar çalışırken alınabilir. Dosya tabanlı yapıda sağlıklı yedek genelde herkesin çıkmasını gerektirir — pratikte bu, yedeğin atlanması demek oluyor.

Raporlama performansı

Veri hacmi büyüdükçe fark açılır. Birkaç yıllık hareket biriken kurulumlarda dönemsel raporların süresi, geçişi tetikleyen en somut gerekçe oluyor.

Sunucu ihtiyacı

SQL tabanlı çalışmak bir veri tabanı sunucusu gerektirir. Bu, donanım ve lisans tarafında ek bir kalem anlamına gelir; kararın maliyet tarafı burada.

En somut kazanım veri kaybı riskinin düşmesidir. Kesinti sonrası onarım ihtiyacı ortadan kalktığında, hem kayıp saatler hem de “acaba bir şey bozuldu mu” belirsizliği biter.

İkincisi yedekleme disiplininin fiilen uygulanabilir hale gelmesi. Herkesin çıkmasını gerektiren bir yedek, uygulamada alınmayan yedektir.

Üçüncüsü büyümeye alan açması: kullanıcı ve veri artışı kurulumu zorlamaz, yalnızca sunucu kaynağı meselesine dönüşür.

Geçişin maliyeti üç kalemdir: sürüm/lisans farkı, veri tabanı sunucusu (donanım ve gerekiyorsa SQL lisansı) ve veri taşıma hizmeti.

Sunucu kalemi genelde hafife alınıyor. Mevcut bir sunucunuz varsa ek maliyet düşük kalır; yoksa donanım kalemi toplamın en büyük parçası olabilir. Küçük kurulumlarda sanal sunucu ya da bulut seçeneği de değerlendirilir.

Veri taşıma maliyeti ise mevcut verinin düzenine bağlıdır. Yıllarca birikmiş, mükerrer kartlarla dolu bir veri setinin taşınması, temiz bir setten belirgin şekilde uzun sürer.

Geçiş öncesi mevcut kurulumun durumunu yerinde çıkarıyoruz: sürüm, veri hacmi, kullanıcı sayısı ve varsa özel geliştirmeler. Bu tespit yazılı bir rapora dönüşüyor ve geçiş kararı bu rapora bakılarak veriliyor.

Geçiş hafta sonuna ya da ay başına denk getiriliyor; eski kurulum bir süre salt okunur tutuluyor. İlk hafta boyunca yerinde destek veriliyor.