Yeni bir meslek eklemek: şema değişikliği mi, satır mı?
Sperare göçmenlik danışmanlarıyla başladı. Yeminli tercümanı eklerken verdiğim karar, ondan sonraki her mesleğin ne kadar süreceğini belirledi.
This post is in Turkish.
Sperare'nin ilk hâlinde tek bir hizmet sağlayıcı türü vardı: göçmenlik danışmanı. Tablo buna göre yazılmıştı — danışmanlık lisansı, çalıştığı ülkeler, uzmanlık alanı.
Sonra yeminli tercüman eklemek gerekti. Ve o an ürünün gerçek şeklini gördüm: bu bir pazaryeri, ve pazaryerinin işi tek bir mesleği taşımak değil, meslek eklemek.
Soru şuydu: her yeni meslek bir şema değişikliği mi olacak, yoksa bir satır mı?
Üç kötü seçenek
Bu problemin standart üç çözümü var ve üçü de kendi cezasıyla geliyor.
Her mesleğe ayrı tablo. Temiz görünüyor: danışman tablosu, tercüman tablosu, her biri kendi alanlarıyla. Ama artık "bana yakınımdaki bütün sağlayıcıları göster" sorgusu her tabloyu birleştirmek zorunda. Meslek sayısı arttıkça arama, mesajlaşma, ödeme, değerlendirme — hepsi çoğalıyor.
Tek tablo, boş kolonlar. Bütün meslekler tek tabloda, herkesin alanı orada. Tercümanın "danışmanlık lisansı" kolonu boş, danışmanın "yemin ettiği dil çifti" kolonu boş. Kısa vadede en hızlısı, orta vadede kolonların yarısı boş bir tablo ve hangi kuralın kime uygulandığını kimse bilmiyor.
Serbest JSON. Ortak alanlar tabloda, mesleğe özel her şey bir JSON alanında. Esnek — ama doğrulama yok, kısıt yok, indeks yok. Altı ay sonra aynı bilgi üç farklı anahtar adıyla kaydedilmiş oluyor.
Seçtiğimiz yol
Kurgu şöyle: ortak bir sağlayıcı çekirdeği, üstünde tipli uzantılar.
Çekirdek her sağlayıcıda aynı olan şeyi taşıyor — kimlik, doğrulama durumu, hizmet verdiği bölgeler, fiyatlandırma, değerlendirme, ödeme hesabı. Arama, mesajlaşma, escrow, itiraz akışı bu çekirdeği tanıyor ve mesleğin ne olduğunu bilmiyor.
Mesleğe özel alanlar ise ayrı bir uzantı tablosunda, çekirdekle bire bir bağlı. Tercümanın yemin bilgisi ve dil çiftleri orada, danışmanın lisansı kendi uzantısında. Her uzantı gerçek kolonlara, gerçek kısıtlara ve gerçek indekslere sahip — JSON'un esnekliğini değil, tablonun disiplinini alıyorsun.
Üstüne bir de meslek tanımı var: hangi belgeler zorunlu, hangi doğrulama adımları gerekli, hangi hizmet tipleri sunulabilir. Bu bir satır, kod değil.
Bir pazaryerinde yeni bir dikey eklemek, kod yazmayı gerektiriyorsa, o pazaryeri tek dikeyli bir üründür.
Neyi ölçtük
Bu ayrımın işe yarayıp yaramadığını anlamanın testi şu: yeni meslek eklerken kaç dosyaya dokunuyorsun?
Doğru kurgu ile dokunduğun yerler bir uzantı tablosu, bir meslek tanımı satırı ve o mesleğe özel form parçası oluyor. Dokunmadığın yerler ise arama, ödeme, escrow, mesajlaşma, itiraz ve raporlama.
Yanlış kurguda ise bu listenin ikinci yarısı da değişiyor — ve orada her yeni meslek bir öncekinden pahalı hâle geliyor.
Bedeli ne
Bu model bedava değil.
Bir birleştirme daha. Bir sağlayıcının tam profilini göstermek her zaman iki tablo demek. Listeleme ekranlarında çekirdek yetiyor, detayda uzantı geliyor.
Uzantı başına göç. Her yeni meslek bir tablo eklemek demek, yani hâlâ bir veritabanı göçü yazıyorsun. JSON kadar hızlı değil.
Çekirdeği doğru çizmek zor. Bir alanın ortak mı mesleğe özel mi olduğuna baştan karar veriyorsun ve bazen yanılıyorsun. Ortak sandığın bir alanın üçüncü meslekte anlamsız olduğunu görüyorsun.
Ama bu hataların hepsi yerel. Yanlış yere koyduğun bir alanı taşımak, bütün sorgu katmanını yeniden yazmaktan ucuz — ve bu model bana en çok onu kazandırdı.