Müşteri, iş emri ve randevu verilerini tasarlamak için veri bütünlüğünü, işlemleri, eşzamanlı istekleri, indeks maliyetlerini ve şema değişikliklerini ele alan uygulamalı rehber.
Veritabanı sorunları çoğu zaman sıradan bir müşteri şikâyetiyle ortaya çıkar: güncellenen adres eski bir teklifi de değiştirir, iki çalışan aynı randevuyu onaylar veya tekrar gönderilen form iki iş emri oluşturur. Bunlar arayüz hatası gibi görünebilir. Oysa asıl soru, kaydın ne anlama geldiği ve hangi iş kurallarının her koşulda korunması gerektiğidir. İyi bir veri modeli bu anlamı ekranlar, entegrasyonlar ve çalışanlar arasında tutarlı kılar.
Tabloları çizmeden önce işletmenin verilerle aldığı kararları yazın. Bir iş ne zaman kesinleşir? Kim iptal edebilir? Hangi bilgiler bugünkü durumu, hangileri geçmişteki anlaşmayı anlatır? Yanıtları web sitesi proje briefine ekleyerek kabul ölçütlerinin parçası yapın. Böylece tasarım görüşmesi yalnızca alan adlarının ve ekranların tartışıldığı bir toplantı olmaktan çıkar.
Test edilebilir bir iş hikâyesiyle başlayın
Restoran ekipmanlarına bakım yapan hayali bir şirket düşünelim. Ofis talebi alıyor, teklif hazırlıyor ve onaydan sonra bir ekibe randevu ayırıyor. Bu örnekte sabah ve öğleden sonra olmak üzere iki sabit zaman dilimi var; bir ekip aynı dilimde yalnızca bir iş üstlenebiliyor. Süreleri çakışabilen randevular için farklı bir model gerekir. Örnekteki basitleştirmeyi gerçek ürünün gereksinimleriyle karıştırmayın.
Hikâyeyi kurallara dönüştürün: iş emri aynı kuruluştaki bir müşteriye bağlı olmalı; kabul edilen teklifin koşulları korunmalı; ekip, tarih ve zaman dilimi için aktif rezervasyon tekrarlanmamalı; iptal işlemi, yapan kişiyi ve gerekçeyi bırakmalı. Başka kuruluşa ait müşterinin seçilmesi gibi yanlış örnekler de isteyin. İstisnalar açıkça konuşulmadığında geliştirici bunları kendi varsayımıyla doldurmak zorunda kalır.
Varlıkları ayırın, geçmişin anlamını koruyun
Başlangıç modeli kuruluş, müşteri, iş emri, teklif kalemi, rezervasyon ve işlem geçmişinden oluşabilir. Her kayda kalıcı bir kimlik verin; müşteri adı ve telefon numarası düzenlenebilir özellikler olsun. İşletme açıkça böyle bir kural koymadıkça ortak telefon numarası ikinci müşterinin açılmasını engellememeli. Bir alanın formda zorunlu olmasıyla kayıt kimliği olması farklı kararlardır.
Güncel iletişim bilgilerini müşteri kaydında tutun. Kabul edilen teklif sürümünde ise anlaşılan hizmet adresinin, müşteri adının ve fiyatların kopyasını saklayın. Buradaki tekrar geçmişi korumak için bilinçli bir tercihtir. Hangi kopyanın esas olduğu belirsiz biçimde her yere adres yazmak başka bir sorundur. Yeniden fiyatlandırmayı eski anlaşmayı değiştirmek yerine yeni teklif sürümü olarak ele alın.
Boş değerlerin anlamını da belirleyin. Randevu alanı boşsa ziyaret henüz planlanmamış mı, yoksa hizmet ziyaret gerektirmiyor mu? Para alanlarında para birimini ve saklama birimini belirtin, yuvarlama kuralında anlaşın, randevuların saat dilimini belgeleyin. Raporu hazırlayan kişi bu ayrıntıları ekran görüntülerinden veya eski e-postalardan çıkarmaya çalışmamalı. Veri sözlüğündeki kısa bir açıklama burada somut değer sağlar.
Temel kuralları veritabanında uygulayın
PostgreSQL, değerleri ve ilişkileri korumak için boş bırakılamama, benzersizlik ve yabancı anahtar kısıtları sunar; ayrıntılar resmî kısıt belgelerinde yer alır. Örneğimizde müşteri ilişkisi kuruluş ve müşteri kimliğini birlikte kapsayabilir. Böylece mevcut fakat yanlış kuruluşa ait müşteriye bağlantı kurulması önlenir.
Her kuralın nerede uygulandığını ve kullanıcıya hangi anlaşılır hatanın gösterileceğini yazın. Negatif miktarın reddedilmesi bir veri kuralıdır. Kabul edilmiş teklifi hangi yöneticinin değiştirebileceği ise yetkilendirme kararı da gerektirir. İlişkinin geçerli olması kullanıcıya o kaydı görme veya değiştirme hakkı vermez. Tasarımı web uygulaması yetkilendirme rehberiyle birlikte değerlendirin.
Onayı tek bir bütün olarak tamamlayın
Veritabanı işlemi, birden çok adımın birlikte tamamlanmasını veya geri alınmasını sağlar; PostgreSQL işlem öğreticisi bu davranışı açıklar. Örnekte iş emrinin onaylanması, rezervasyonun oluşturulması ve onay olayının kaydedilmesi ortak bir başarı sınırına sahip olmalı. Rezervasyon hâlâ başarısız olabilecek durumdayken ekranda başarı gösterilmemeli.
Haricî e-posta teslimatını bu veritabanı garantisine dahil etmeyin. Onayla birlikte gönderilmeyi bekleyen bir bildirim kaydı oluşturun; ayrı bir görev bildirimi göndersin ve denemeleri izlesin. Çalışan, kesinleşen randevuyla henüz iletilmemiş bildirimi ayırt edebilmeli. Tekrarlanan gönderimlerin etkisini entegrasyon güvenilirliği planında tanımlayın. Bildirimin gecikmesi iş emrinin yeniden açılmasına neden olmamalı.
Aynı anda gelen istekleri sınayın
İki çalışan sabah dilimini boş görüp farklı işleri aynı anda onaylayabilir. Ekrandaki uygunluk kontrolü rezervasyon değildir. Bu sabit dilimli modelde aktif rezervasyon için kuruluş, ekip, tarih ve dilim birlikte benzersiz olmalı. Kaybeden istek anlaşılır bir çakışma yanıtı almalı ve başka zaman seçebilmelidir. Daha önce kazanmış rezervasyon bu sırada silinmemeli.
İşlemler her eşzamanlılık sorununu kendiliğinden çözmez; yalıtım düzeyi davranışı etkiler ve bazı durumlarda yeniden deneme gerekir. İşlem yalıtımı belgeleri bu ayrımları açıklar. Beklenen sonucu belli olan eşzamanlı bir test yazın. Aynı ağ isteğinin tekrarında, saklanmış istek anahtarını ve sonucunu kullanın; anahtar farklı içerikle yeniden gönderilirse reddedin.
İndeksleri iş sorularına göre seçin
İndeksler satırlara erişimi iyileştirebilir, ancak veri değişikliklerine ek yük getirir; bu denge PostgreSQL indeks girişinde açıklanır. Ekibin günlük randevuları, kuruluşun bekleyen onayları veya müşterinin tarih sıralı işleri gibi önemli sorguları belirleyin. Bu sorgular için indeks önerin ve gerçek çalışma dağılımını temsil eden verilerle ölçün.
Filtrede göründüğü için her alanı indekslemeyin. Her indeksin hangi soruya hizmet ettiğini, beklenen okuma ve yazma yükünü ve faydasının kanıtını kaydedin. Karmaşık aylık rapor ayrı bir okuma düzeni gerektirebilir. Kararı ölçümden sonra verin ve raporun ne kadar güncel olması gerektiğini belirtin. Anlık randevu ekranıyla dönemsel yönetim raporunun aynı gecikme beklentisine sahip olduğunu varsaymayın.
Şema değişikliğini ve kurtarmayı planlayın
Şirket tek müşteri adresinden birden çok hizmet konumuna geçerse önce yeni modeli ekleyin. Verileri doğrulanabilir aşamalarda taşıyın, eksik adresleri nasıl ele alacağınızı belirleyin ve eski bağımlılığı kaldırmadan okuma ile yazmayı güncelleyin. Hassas bilgilerden arındırılmış bir üretim dışı ortamda prova yapın; geri dönüş noktasını ve karar sorumlusunu önceden belirleyin.
Başarılı yedekleme tek başına kurtarma kanıtı değildir. Ayrı ortamda geri yükleme yaparak müşterileri, iş emirlerini ve ilişkileri kontrol edin. Bu çalışmayı bakım ve güvenlik planına, veri davranışlarını ise yayına çıkış kontrol listesine dahil edin.
Tasarım onayından önce sorulacaklar
- Her kaydın tanımı, sorumlusu ve değiştirme veya silme politikası belli mi?
- Müşteri güncellemeleri eski anlaşmaları koruyor mu?
- Çakışan isteklerde veya kayıt sonrası bağlantı kesildiğinde sonuç ne oluyor?
- Çalışanlar işin durumunu kayıtlardan açıklayabiliyor mu?
- Taşıma ve geri yükleme denendi mi, performansı kim izleyecek?
Amaç gelecekteki her özelliği tahmin etmek değildir. Bugünkü işi açıkça anlatan, önemli kuralları koruyan ve değişim için anlaşılır bir yol bırakan küçük bir model kurmaktır.
Yapay zekâ desteğiyle hazırlanmıştır; doğrulama için teknik kaynaklar listelenmiştir.