Vaka Çalışması · Spor & federasyonlar
TBF: Basketbol Yönetim Sistemi'nin veritabanı — eski sistemden yeni sisteme mimari ve geçiş
Türkiye Basketbol Federasyonu kendi yazılım ekibiyle yeni bir Basketbol Yönetim Sistemi yazarken, sistemin üzerinde çalışacağı veritabanını tasarladık ve eski sistemdeki 454 tablo, beş milyon kaydı modül modül yeni yapıya taşıdık. Adlandırma standardı, 1.685 kolon eşlemesi, 226 yabancı anahtar, belge dışa aktarımı, kesim günü aktarımı ve dokümantasyon. Federasyonun bugün kullandığı BYS bu veritabanı üzerinde çalışıyor.
- 454 → 121
- Tablo
- 1.685
- Kolon eşlemesi
- 226
- Yabancı anahtar
- ~5 M
- Kayıt
Eski sistemden yeni modüler yapıya
Eski kolon → yeni kolon, tek eşleme dosyasında
Oluşturma ve silme scriptleriyle birlikte
Kimlik işlemleri, kişiler, maçlar, istatistikler
Problem
2019’da Türkiye Basketbol Federasyonu, yıllardır kullandığı yönetim yazılımının yerine kendi yazılımcılarıyla yeni bir Basketbol Yönetim Sistemi yazmaya başlamıştı: .NET, SQL Server, web üzerinden erişilen responsive bir uygulama. Ekranlar tasarlanıyordu; ama ekranların üzerinde çalışacağı veritabanı katmanı boştu.
Eski sistemin veritabanı 454 tablo ve beş milyona yakın kayıt taşıyordu — kişiler, kimlik işlemleri, takımlar, maçlar, istatistikler, hakedişler, telefonlar, adresler. Yapısı bir tedarikçi ürününün genel şemasıydı: tablo adları ürünün önekleriyle, kolonlar ürünün kurallarıyla, belgeler veritabanının içinde BLOB olarak. Bu yapıyı olduğu gibi yeni sisteme taşımak yeni sistemi eski sistemin kopyası yapardı; sıfırdan tasarlayıp veriyi geride bırakmak ise on yılların sicil ve lisans geçmişini kaybetmek demekti.
İş şuydu: yeni uygulamanın ihtiyaç duyduğu tabloları temiz bir standartla tasarlamak, eski verinin tamamını bu tablolara doğru biçimde aktarmak ve federasyonun kendi ekibinin bunu sürdürebileceği şekilde teslim etmek.
Önce notasyon
İlk toplantıda kod yazılmadı; adlandırma kuralları konuşuldu. Yeni veritabanının her tablosu, kolonu ve prosedürü aynı kurala uyacaktı:
| Kural | Karar |
|---|---|
| Tablo öneki | modul_ iş tabloları, tanim_ referans tabloları, sistem_ altyapı tabloları |
| Kimlik | Her tabloda ID; eski sistemin kimliği ExID olarak yanında taşınır |
| Referans | Bir tabloda bir tanımın ID’si varsa tanımın kendisi de yanında tutulur — ekranlar JOIN’siz okur |
| Veri tipi | Tanım için nvarchar, açıklama için ntext, tarih için smalldatetime; tarih kolonları Talep_Tarih, Onay_Tarih gibi açıklamalı |
| Prosedür | sp_ öneki; bir tablonun insert/update prosedürü tablonun adını taşır |
| Belge | Veritabanında değil, dosya sisteminde: /Yuklemeler/Icerik/[Dizin]/[Dosya]-[satır]-[GUID].[uzantı] |
ExID kararı geçişin sigortasıydı: her yeni kayıt eski kaydını biliyor; aktarım sonrası herhangi bir tutarsızlık eski sisteme kadar geri izlenebiliyor, kesim gününde yalnızca yeni eklenen kayıtlar ayırt edilebiliyor.
Modül modül döngü
Yeni sistemin modülleri belliydi: sicil-lisans (kişi, kimlik, kimlik işlemleri, etkinlik), kulüp işlemleri (takımlar, tüzel kişiler, takım işlemleri), maç, fikstür, istatistik. Her modül için aynı döngü işledi:
- İş takibinde görev açılır; eski sistemde modülü besleyen tablolar bulunur.
- Tablo listesi TBF’ye gönderilir; onay alınır ya da liste düzeltilir.
- Tablolar notasyona göre oluşturulur; eski kolon → yeni kolon eşlemesi tek bir dosyaya işlenir.
- Veri aktarılır, doğruluğu kontrol edilir, test için TBF’ye verilir.
- TBF’den onay gelince görev kapanır; sıradaki modüle geçilir.
Sonunda 121 tablo — 42 modül tablosu, 78 tanım tablosu — ve 119 eski tablodan 1.685 kolon eşlemesi çıktı. Her tablonun scripti ayrı bir dosyada; hepsi, doğru sırayla, tek bir aktarım scriptinde birleşti. O script 17 sürüm gördü: her TBF testinden sonra düzeltilip baştan çalıştırıldı, böylece kesim günü hiçbir adım elle yapılmadı.
Teknik ayrıntılar
Belgeler. Eski sistem sözleşmeleri, fotoğrafları, formları BLOB olarak tabloların içinde tutuyordu; en büyük tablolardan biri yalnızca eklerdi. Aktarım sırasında bir cursor her kaydı dolaşıyor, eki bir stored procedure ile dosya sistemine yazıyor ve yeni kayda dosyanın yolunu koyuyor. Veritabanı küçüldü, belgeler yedeklenebilir dosyalar oldu.
Bütünlük ve hız. 226 yabancı anahtar tanımlandı — her biri “yoksa oluştur / varsa sil” biçiminde, aktarım öncesi kaldırılıp sonrasında geri konabilecek şekilde. Eski kimlik üzerindeki 122 indeks yeni ID kolonlarına taşındı. Eski sistemdeki tetikleyiciler ve en sık çalışan sorgular yeni yapıya göre yeniden ele alındı.
Tekrar kayıtlar. Yıllar içinde aynı kişi birden fazla kez açılmıştı. Tekrar kayıtları bulan ve birleştiren scriptler yazıldı; hatalı kayıtlar ayrı bir listede federasyona sunuldu.
Kesim günü. Aktarım bir kez değil, birkaç kez yapıldı: önce tam veriyle test, sonra belirlenen gün ve saatte eski sistemdeki en güncel verinin son aktarımı. Aktarım scriptleri, eşleme dosyası ve dokümantasyon TBF’ye teslim edildi; teslimden sonra 60 gün e-posta üzerinden soru desteği verildi.
Sonuç
Federasyonun kendi ekibinin yazdığı BYS, bu veritabanı üzerinde canlıya çıktı ve bugün de onun üzerinde çalışıyor. Sicil, lisans, kulüp, maç ve istatistik verisi kesintisiz taşındı; eski sistemden gelen her kayıt ExID ile izlenebilir kaldı. Notasyon, ekibin sonraki geliştirmeleri için standart olarak teslim edildi.
Altı yıl sonra aynı federasyon için hakem ve değerlendirici atama sistemini kurduk.