Ülke verisinin güncelliği, çoğu ekipte “bir kere doğru aktardık, artık sorun yok” varsayımıyla bir kenara bırakılır; oysa ülke adları, para birimleri ve idari yapılar zaman içinde değişir ve bir kez alınmış her liste bu değişimlerin gerisinde kalır. Sorun, listenin eskimesi değil, eskidiğinin fark edilmemesidir. Bu yazıda verinin neden eskidiğini, bir kaydın hangi bilgileri taşıması gerektiğini ve güncellemenin hangi yollarla yapılabileceğini ele alıyoruz.
Ülke verisi neden zamanla eskir?
Bir ülke listesi, alındığı günün fotoğrafıdır. O günden sonra dünyada olan hiçbir değişiklik listeye yansımaz; liste yanlış olduğu için değil, durduğu için eskir. Bu ayrım önemlidir: eskiyen liste hata üretmez, sadece gerçeği eksik anlatır ve bu eksiklik sessizce büyür.
Değişimlerin bir kısmı görünürdür ve hemen fark edilir. Bir ülkenin adının değişmesi, kullanıcıların soru sormasına yol açar ve ekip konuyu ele alır. Aynı şekilde para birimi değişiklikleri de genellikle hızlı fark edilir; çünkü tutarlar yanlış görünür.
Değişimlerin bir kısmı ise görünmezdir ve asıl risk buradadır. Bir idari bölümün adı değiştiğinde, eski ad yalnızca bazı kayıtlarda yanlış görünür. Bir bölgenin statüsü değiştiğinde, o bölgeye ait kayıtlar hangi gruba girdiğini bilemez hale gelir. Bu tür değişiklikler hata mesajı üretmez; yalnızca yanlış sonuç üretir.
Üçüncü grup değişiklik ise veri yapısının kendisiyle ilgilidir. Yeni bir alan gerekli hale gelebilir, kullanımdan kalkmış bir kod tarihsel kayıtlarda kalabilir. Bu değişiklikler, listeyi tutan ekibin iş yapış biçimini de değiştirir; çünkü artık yalnızca değer değil, şema da güncellenmelidir.
Ad değişiklikleri, para birimleri ve idari yapı
Değişiklikleri üç başlıkta toplamak, hangi kaydın hangi bilgiyi taşıması gerektiğini netleştirir.
| Değişiklik türü | Neyi etkiler | Fark edilme biçimi |
|---|---|---|
| Ad değişikliği | Görünen metin ve arama eşleşmeleri | Kullanıcı bildirimi |
| Para birimi değişikliği | Tutarların yorumu | Tutar uyuşmazlığı |
| İdari yapı değişikliği | Alt bölüm listeleri ve gruplar | Sessiz yanlış sonuç |
| Kod değişikliği | Kayıtların birleştirilmesi | Eski kaydın eşleşmemesi |
Tablodan çıkan sonuç, değişikliklerin fark edilme hızının türüne göre değiştiğidir. En yavaş fark edilenler, en çok zarar verenlerdir; çünkü düzeltilene kadar üretilen bütün kayıtlar aynı hatayı taşır. Bu yüzden kaynağı izlemek, yalnızca kullanıcı bildirimlerini beklemekten daha güvenilirdir.
Değişikliklerin bir kısmı aynı anda birden fazla alanı etkiler. Bir ad değişikliği, arama eşleşmelerini ve görünen metni birlikte etkiler; bir kod değişikliği ise kayıtların birleştirilmesini ve raporların sürekliliğini. Bu yüzden bir değişiklik geldiğinde etkisini alan alan değil, ilişkiler üzerinden değerlendirmek gerekir.
Aynı başlık, para birimi ve dönem bilgisinin tutulduğu her yerde karşımıza çıkar; bu alanların birlikte nasıl ele alındığını maaş, para birimi ve dönem yazısında bulabilirsiniz.
Alma tarihi neden mutlaka saklanmalı?
Bir kaydın doğru olup olmadığını anlamanın tek yolu, ne zaman alındığını bilmektir. Alma tarihi olmayan bir kayıt, iki farklı sistemde iki farklı değer taşıdığında hangisinin yeni olduğunu söylemez. Bu belirsizlik, tartışmayı veriye değil hatırlamaya bağlar.
Alma tarihinin yanında kaynağın da tutulması gerekir. Hangi kaynaktan alındığı bilinmeyen bir değer, bir çelişki durumunda savunulamaz. Kaynak, değerin kendisi kadar önemli bir alandır; çünkü değer değiştiğinde nereye bakılacağını söyleyen odur.
Üçüncü alan, kapsamdır. Bir kayıt hangi alanları kapsadığını belirtmiyorsa, eksik bir veri ile uygulanamaz bir alanı ayırt etmek imkânsız hale gelir. Kapsam bilgisi, verinin nerede bittiğini gösterir.
Bu üç alanı birlikte tutmak, veri kümesini denetlenebilir kılar. Bir uyuşmazlık çıktığında soru “kim haklı” olmaktan çıkar, “hangi kayıt daha yeni ve hangi kapsamda” sorusuna dönüşür. Bu, cevaplanabilir bir sorudur.
Geçmiş kayıtlar yeni veriyle neden değiştirilmemeli?
Veri kümesi güncellendiğinde, akla ilk gelen çözüm eski kayıtları da yeni değerlere çevirmektir. Bu çözüm temiz görünür ama geçmişi bozar: geçen yıl kesilmiş bir belge, bugünkü veriyle yeniden üretildiğinde artık farklı bir metin verir.
Bunun nedeni, geçmiş kayıtların yalnızca veri değil, bir işlemin kanıtı olmasıdır. Bir belge, kesildiği andaki veriyi taşır; sonradan yapılan bir düzeltme o belgeyi geriye dönük olarak değiştirmemelidir. Aksi halde iki farklı tarihte alınan iki çıktı, aynı işlem için birbirini tutmayan sonuçlar verir.
Doğru yaklaşım, güncel veriyi ayrı tutmak ve geçmiş kaydın yanında o günkü değerin bir kopyasını saklamaktır. Böylece güncel liste ilerlerken geçmiş kayıtlar oldukları yerde kalır. Bu, depolama açısından biraz daha maliyetlidir; karşılığında denetlenebilirlik kazanılır.
Bu kural, güncellemenin kendisini de kolaylaştırır. Geçmişi değiştirmek zorunda olmayan bir güncelleme, yalnızca güncel katmanı ilgilendirir; geri alma gerektiğinde de tek bir katman geri alınır.
İki kaynak birbiriyle çeliştiğinde ne yapılır?
İki yetkili kaynak aynı alan için farklı değer verdiğinde, her seferinde yeniden karar vermek yorucu ve tutarsız bir yol olur. Bunun yerine bir kaynağı temel alıp, diğerinden gelen farkları bir istisna listesinde toplamak gerekir.
Temel kaynağı seçerken ölçütü yazılı tutun. Hangi kaynağın daha sık güncellendiği, hangi alanları kapsadığı ve hangi biçimde yayımlandığı bu ölçütün parçalarıdır. Ölçüt yazılıysa, kaynak değiştiğinde karar da aynı gerekçeyle yeniden verilebilir.
İstisna listesi, çelişkinin kendisini taşır: hangi alan, hangi iki değer, hangi gerekçeyle temel kaynağın dışında bırakıldı. Liste küçük tutulmalıdır; büyüdüğünde temel kaynağın artık temel olmadığı anlaşılır.
Üçüncü yol, çelişkiyi gizlemektir; bu en kötüsüdür. Bir alanı iki kaynaktan birinden alıp diğerini sessizce yok saymak, ileride aynı çelişkiyi daha büyük bir maliyetle geri getirir. Çelişkiyi kaydetmek, çözümün yarısıdır.
Geliştiriciler için: kaynağı ve tarihi birer alan olarak tutmak
Kaynağı ve alma tarihini belgeye yazmak yeterli değildir; bunlar veri modelinin parçası olmalıdır. Her kayıt hangi kaynaktan geldiğini ve ne zaman alındığını taşırsa, güncelleme işi tek tek kayıtlar üzerinden değil sorgular üzerinden yürütülebilir.
Güncelleme stratejisini baştan seçin. Bütün kümeyi belirli aralıklarla yenilemek denetlenmesi kolaydır; yalnızca değişen kayıtları eklemek daha hafiftir ama kaynağın değişiklikleri güvenilir biçimde bildirmesini gerektirir. Üçüncü yol, yalnızca bildirilen sorunları düzeltmektir; en ucuzudur ve en çok gecikmeyi üretir.
Hangi stratejiyi seçerseniz seçin, geri alınabilir olsun. Bir güncelleme bir alanı beklenmedik biçimde değiştirdiğinde, önceki duruma dönmenin bir yolu bulunmalıdır. Sürüm numarası ve değişiklik kaydı, bu yolu açar.
Testleri de tarihe bağlayın. Bir alanın beklenen değeri zamanla değişiyorsa, testin hangi veri sürümüne göre yazıldığını bilmek gerekir. Aksi halde doğru çalışan bir test, veri güncellendiği gün yanlış sebeple kırmızıya döner ve ekibi yanlış yere yönlendirir.
Sonraki adımlar
Veri kümesi güncellenirken hangi alanların dolu olduğunu ölçmek için ülke verisi kapsam listesi yazısına bakabilirsiniz. Küme birkaç ülkeden onlarca ülkeye büyüdüğünde güncellemenin nasıl yürütüleceğini ise test verisini ülkeler arasında ölçeklemek yazısında ele alıyoruz. Değişiklikleri ülke bazında karşılaştırmak için sitemizdeki ülke ve bölge dizini sayfasını kullanabilirsiniz.
Bu yazıdaki kaynak adları, alma tarihleri, sürüm numaraları ve değişiklik örnekleri yalnızca yazım biçimini göstermek için uydurulmuş örneklerdir; gerçek bir veri kaynağına, gerçek bir yayım tarihine ya da gerçek bir sürüme işaret etmez ve resmî bir kaynak olarak anılamaz.