Kodsuz uygulamalarda form doğrulaması için veritabanı kısıtları

Kötü form verisi neden hızla yayılır

Kötü veri nadiren tek bir yerde kalır. Formda girilen yanlış bir değer, uygulamanın her parçası tarafından kopyalanabilir, referans alınabilir ve güvenilir hale gelebilir.

Genellikle küçük başlar: biri e-postanın sonuna boşluk ekler, yanlış müşteriyi seçer ya da alan negatif miktara izin verdiği için eksi bir miktar girer. Form bunu kabul eder, sistem de doğruymuş gibi işlem yapar.

Sonrası hızla yayılır. Raporlar yanlış toplamları gösterir, otomasyonlar yanlış kayıtlarda çalışır ve müşteri mesajları karışık alanları çeker, profesyonel olmayan görünür. Ekipler özel tablolar gibi geçici çözümler oluşturur; bu da daha fazla uyumsuzluk yaratır. En kötüsü, aynı kötü değer genellikle daha sonra tekrar ortaya çıkar çünkü seçenek olarak görünür veya yeni kayıtlara kopyalanır.

Veriyi sonra düzeltmek yavaş ve risklidir çünkü temizlik genellikle tek bir düzenleme değildir. Kötü değerin gittiği her yeri bulmanız, ilgili kayıtları güncellemeniz ve buna bağlı her şeyi yeniden kontrol etmeniz gerekir. Bir “basit” düzeltme iş akışlarını bozabilir, yinelenen bildirimler tetikleyebilir veya denetim geçmişini bulanıklaştırabilir.

Form doğrulaması için veritabanı kısıtlarının amacı, bu zincirleme reaksiyonu ilk adımda durdurmaktır. Veritabanı imkansız veya tutarsız veriyi reddettiğinde, sessiz hataları önlersiniz ve UI'da yardımcı geri bildirim göstermek için net bir an elde edersiniz.

Bir no-code aracıyla yapılmış iç sipariş formunu hayal edin: bir sipariş eksik müşteri bağlantısı veya tekrar eden sipariş numarası ile kaydedilirse faturaları, sevkiyat görevlerini ve gelir raporlarını zehirleyebilir. Gönderme anında yakalamak, sonrasını temiz tutar ve can yakacak düzeltmelerin önüne geçer.

Veritabanı kısıtları, jargon olmadan

Veritabanı kısıtları, veritabanında yaşayan basit kurallardır. Veri kaydedildiğinde, verinin nereden geldiğine bakılmaksızın (web formu, mobil ekran, içe aktarma veya API çağrısı), bu kurallar çalışır. Bir kural ihlal edilirse, veritabanı kaydı reddeder.

Bu, yalnızca UI doğrulamasından büyük farktır. Bir form Kaydet’e basmadan önce alanları kontrol edebilir, ama bu kontroller kolayca gözden kaçabilir veya atlanabilir. Başka bir ekran aynı kuralı unutabilir. Bir otomasyon doğrudan veritabanına yazabilir. Yakında verinin bir yerde doğru görünüp başka yerde raporları bozduğu bir durumunuz olur.

Veritabanı kısıtlarıyla form doğrulamasından bahsederken kastedilen budur: veritabanını son yargıç yapın ve UI’yı kullanıcıyı yönlendirecek şekilde tasarlayın ki nadiren o duvara çarpsınlar.

Çoğu gerçek uygulama üç temel ile çok şeyi kaplayabilir:

• Unique: “Bu değer tek olmalı.” Örnek: e-posta, çalışan kimliği, fatura numarası.
• Check: “Bu koşul doğru olmalı.” Örnek: miktar > 0, start_date <= end_date.
• Foreign key: “Bu başka bir tabloda gerçek bir kayda işaret etmeli.” Örnek: her sipariş mevcut bir müşteriye referans vermeli.

Kısıtlar, no-code uygulamalarda daha da önemlidir çünkü genellikle veriyi oluşturmanın veya güncellemenin birden fazla yolu vardır. Yöneticiler için bir web uygulamanız, saha personeli için bir mobil uygulamanız ve arka planda kayıt yazan otomasyonlar olabilir. Kısıtlar tüm bu yolları tutarlı tutar.

Ayrıca hataları daha anlaşılır hale getirmenizi sağlar. Kötü verinin içeri sızmasına izin verip sonra düzeltmek yerine, “O fatura numarası zaten var” veya “Lütfen geçerli bir müşteri seçin” gibi odaklanmış mesajlar gösterebilir ve veritabanını baştan temiz tutabilirsiniz.

Kısıttan açık, insan dilinde hata mesajına

Kısıtlar kötü veriyi durdurmada iyidir, ama ham veritabanı hataları genellikle geliştiriciler için yazılmıştır, forma veri giren kişi için değil. Amaç basit: kural veritabanında kalsın, sonra başarısızlığı ne olduğunu ve nasıl düzelteceklerini söyleyen bir mesaja çevirin.

Her kısıtı küçük bir “hata sözleşmesi” gibi ele alın: neyin yanlış olduğunu ve nasıl düzeltebileceklerini söyleyen iki parçalı bir mesaj. UI dostu kalırken veri kurallarından ödün vermeyin.

Birkaç işe yarayan çeviri örneği:

• Kötü: “Unique constraint violation on users_email_key”

• İyi: “Bu e-posta zaten kullanılıyor. Giriş yapmayı deneyin veya farklı bir e-posta kullanın.”

• Kötü: “Check constraint failed: order_total_positive”

• İyi: “Toplam 0'dan büyük olmalıdır. En az bir ürün ekleyin veya miktarı düzeltin.”

• Kötü: “Foreign key violation on customer_id”

• İyi: “Geçerli bir müşteri seçin. Eğer yeni bir müşteri ise önce müşteriyi oluşturun.”

Mesajı nerede gösterdiğiniz, kelimeler kadar önemlidir. Tek alan hatasını o alanın yanına koyun. Alanlar arası kurallar için (ör. “bitiş tarihi başlangıç tarihinden sonra olmalı”) bir form düzeyinde banner genellikle daha açıktır.

Mesaj stillerini küçük tutun. Çoğu sorun için inline alan metni, alanlar arası kurallar için küçük bir banner ve kısa onaylar için bir toast yeterlidir. Web ve mobil arasında da kelime seçimlerini tutarlı tutun. Eğer web formunuz “Geçerli bir müşteri seçin” diyorsa, mobil uygulama “Invalid FK” dememelidir. Aynı kısa fiilleri (“Seç”, “Gir”, “Kaldır”) ve tonu kullanın ki kullanıcılar ne bekleyeceklerini öğrensin.

AppMaster ile inşa ediyorsanız, bu eşleme kasıtlı olarak tasarladığınız bir şeydir: veritabanı katı kalır, UI ise hataları sakin, spesifik rehberliğe çevirir.

Adım adım: önce kuralları kurun, sonra formu

Formu önce tasarlarsanız, kenar durumların peşinden koşarsınız. Veri kurallarını önce tasarlarsanız, UI zaten veritabanında var olan kuralları yansıttığı için daha basit olur.

Pratik bir sıra:

1. Gerçekten önemli birkaç alanı yazın. “Geçerli”yi düz cümlelerle tanımlayın. Örnek: “E-posta benzersiz olmalı”, “Miktar 1 veya daha fazla olmalı”, “Her siparişin bir müşterisi olmalı”.
2. Tabloları ve ilişkileri modelleyin. Ekran çizmeye başlamadan önce neyin nereye ait olduğunu kararlaştırın.
3. Değiştirilemez kurallar için kısıtları ekleyin. Yinelenmeleri engellemek için unique, her zaman doğru olanlar için check ve ilişkiler için foreign key kullanın.
4. UI'ı kısıtlarla eşleştirin. Zorunlu alanları işaretleyin, doğru giriş tiplerini kullanın ve basit ipuçları ekleyin. UI kullanıcıyı yönlendirmeli, ama veritabanı son kapı olmalı.
5. Kasıtlı olarak kırmaya çalışın. Kirli değerleri yapıştırın, kopyaları deneyin ve eksik ilişkili kayıtları seçmeyi deneyin. Sonra etiketleri ve hata metinlerini, neyi düzeltmeleri gerektiğinin bariz olana dek iyileştirin.

Hızlı örnek

Dahili “Yeni Sipariş” formu yapıyorsunuz diyelim. Kullanıcıyı müşteri adına göre arama yapmaya izin verebilirsiniz, ama veritabanı yalnızca gerçek bir Customer ID kabul etmelidir (foreign key). UI'da bu, aranan bir seçim kutusu olur. Kullanıcı müşteri seçmeden gönderirse, mesaj basitçe “Bir müşteri seçin” diyebilir, sonraki aşamada kafa karıştırıcı bir kaydetme hatası yerine.

Bu, kuralları web ve mobil formlar arasında tekrarlamadan tutarlı kılar.

İnsanların gerçekte oluşturduğu kopyaları önleyen unique kısıtları

Unique kısıtı, “aynı şeyin farklı girilmesi”nin birikmesini engellemenin en basit yoludur. Form gözden kaçırsa bile veritabanı tekrar eden değeri reddeder.

İnsanların kazara tekrarladığı değerlerde unique kullanın: e-postalar, kullanıcı adları, fatura numaraları, varlık etiketleri, çalışan kimlikleri veya elektronik tablolardan yapıştırılan bilet numaraları.

İlk karar kapsamdır. Bazı değerlerin sistem genelinde benzersiz olması gerekir (bir kullanıcı adı). Diğerleri yalnızca üst grup içinde benzersiz olmalı (bir organizasyon içindeki fatura numarası veya depo içindeki varlık etiketi). Geçerli verileri engellememek için kapsamı amaçlı seçin.

Pratik düşünme şekli:

• Global benzersiz: sistemde bir kez olmalı (kullanıcı adı, genel tanıtıcı)
• Organizasyon bazlı benzersiz: bir şirket/ekip içinde benzersiz (invoice_number + org_id)
• Lokasyon bazlı benzersiz: bir sahada benzersiz (asset_tag + location_id)

Çakışmayla başa çıkma şekli, kural kadar önemlidir. Unique kısıtı başarısız olduğunda sadece “zaten var” demeyin. Neyi çarpıştırdığını ve kullanıcı ne yapabileceğini söyleyin. Örneğin: “Fatura numarası 1047 Acme Co. için zaten mevcut. 1047-2 deneyin veya mevcut faturayı açın.” Eğer UI güvenli bir şekilde mevcut kayda referans verebiliyorsa, oluşturulma tarihi veya sahip gibi küçük bir bilgi kullanıcının kurtulmasına yardımcı olabilir (gizli bilgiler açığa çıkmadan).

Düzenlemeler özel dikkat ister. Yaygın hata, güncelleme işlemini yeni bir kayıt gibi ele alıp kaydın kendisine karşı “çakışma” bildirmektir. Kaydetme mantığınızın mevcut kaydı tanıdığından emin olun ki aynı satırla karşılaştırma yapmasın.

AppMaster'da unique kuralı önce Data Designer'da tanımlayın, sonra formda kullanıcı dostu bir mesajla eşleştirin. Veritabanı son kapı olarak kalsın, UI ise gerçek kuralı açıkladığı için dürüst olsun.

Her zaman doğru olması gereken kurallar için check kısıtları

Check kısıtı, veritabanının her satıra, her seferinde uyguladığı bir kuraldır. Biri kuralı bozan bir değer girerse, kayıt başarısız olur. Farklı ekranlardan, içe aktarmalardan veya otomasyonlardan gelen veriler için, asla ihlal edilmemesi gereken kurallar için tam da istemeniz gereken şey budur.

En iyi check'ler basit ve öngörülebilirdir. Kullanıcı kuralı tahmin edemezse tekrar tekrar hata alır ve formu suçlar. Kontrolleri gerçeklere odaklayın, karmaşık politikaları değil.

Hızlı fayda sağlayan yaygın check kısıtları:

• Aralıklar: miktar 1 ile 1000 arasında, yaş 13 ile 120 arasında
• İzin verilen durumlar: status Draft, Submitted, Approved veya Rejected olmalı
• Pozitif sayılar: amount > 0, indirim 0 ile 100 arasında
• Tarih sırası: end_date >= start_date
• Basit mantık: if status = Approved then approved_at is not null

Check'leri kullanıcı dostu yapan hile, UI mesajını nasıl ifade ettiğinizdir. Kısıt adını tekrarlamayın. Kullanıcıya neyi değiştirmesi gerektiğini söyleyin.

İyi örnekler:

• “Miktar 1 ile 1000 arasında olmalıdır.”
• “Bir durum seçin: Draft, Submitted, Approved veya Rejected.”
• “Bitiş tarihi, başlangıç tarihiyle aynı veya daha sonra olmalıdır.”
• “Tutar 0'dan büyük olmalıdır.”

Kodsuz bir yapıcıda (ör. AppMaster) anında geri bildirim için aynı check'leri formda yansıtmak uygundur, ama veritabanındaki check kısıtını son muhafız olarak tutun. Böylece ileride yeni bir ekran eklense bile kural geçerli kalır.

İlişkileri gerçek tutan foreign key'ler

Foreign key (FK) basit bir söz verir: bir alan başka bir kayda işaret ediyorsa, o kaydın gerçekten var olması gerekir. Bir Order bir CustomerId'ye sahipse, veritabanı Customers tablosunda olmayan müşteriye işaret eden siparişi reddeder.

Bu önemlidir çünkü ilişki alanları “neredeyse doğru” verilerin göründüğü yerdir. Biri müşteri adını biraz yanlış yazabilir, eski bir ID yapıştırabilir veya dün silinmiş bir kaydı seçebilir. FK yoksa bu hatalar raporlama, faturalama veya destek çalışmasında sorun çıkarana kadar normal görünür.

UI deseni basittir: serbest metin yerine güvenli seçimler kullanın. “Müşteri” için bir metin girişi yerine, seçici, arama veya autocomplete kullanın ve arka planda müşterinin ID'sini kaydedin. No-code bir araçta (örneğin AppMaster bileşenleriyle modellerinize bağlı) bu genellikle bir dropdown veya arama listesini Customers tablosuna bağlamak ve seçilen kayıt referansını (label değil) kaydetmek anlamına gelir.

Referans kaydı eksik veya silinmişse davranışı önceden kararlaştırın. Çoğu ekip şu yaklaşımlardan birini benimser:

• İlişkili kayıtlar varken silmeyi engelle (müşteriler, ürünler, departmanlar için yaygın)
• Silmek yerine arşivle (ilişkileri bozmadan geçmişi koru)
• Ancak gerçekten güvenliyse cascade delete uygula (iş verisi için nadir)
• İlişki isteğe bağlıysa referansı boş yap

Ayrıca “ilişkili kayıt oluştur” akışını planlayın. Bir form kullanıcıyı başka bir yere gitmeye, müşteri oluşturmaya ve sonra geri gelip her şeyi tekrar yazmaya zorlamamalı. Pratik bir yaklaşım, önce müşteriyi oluşturan ve yeni ID'yi döndürüp otomatik seçen bir “Yeni müşteri” aksiyonudur.

FK başarısız olursa ham veritabanı mesajı göstermeyin. Ne olduğunu sade bir dille söyleyin: “Lütfen mevcut bir müşteri seçin (seçilen müşteri artık mevcut değil).” Bu tek cümle, kırık bir ilişkinin yayılmasını önler.

UI akışında kısıt hatalarını ele alma

İyi formlar hataları erken yakalar, ama kendilerini son yargıç gibi göstermemelidir. UI kullanıcıyı daha hızlı hareket ettirir; veritabanı ise kaydın kötü olmamasını garanti eder.

İstemci tarafı kontroller görünür sorunlar içindir: zorunlu alan boş, e-postada @ yok ya da sayı makul aralığın çok dışında. Bunları hemen göstermek formu duyarlı hissettirir ve başarısız gönderimleri azaltır.

Sunucu tarafı kontroller ise kısıtların gerçek işini yaptığı yerdir. UI bir şeyi kaçırsa (veya iki kişi aynı anda gönderse bile) veritabanı kopyaları, geçersiz değerleri ve kırık ilişkileri engeller.

Bir kısıt hatası sunucudan döndüğünde yanıtı öngörülebilir tutun:

• Tüm kullanıcı girdisini formda tutun. Sayfayı sıfırlamayın.
• Soruna neden olan alanı vurgulayın ve yakınında kısa bir mesaj ekleyin.
• Sorun birden fazla alanı ilgilendiriyorsa kısa bir üst mesaj gösterin ama yine de en uygun alanı işaretleyin.
• Güvenli bir sonraki eylem sunun: değeri düzenle veya mantıklıysa mevcut kaydı aç.

Son olarak, ne olduğunu kayıt altına alın ki formu iyileştirebilesiniz. Kısıt adını, tablo/alını ve hatayı tetikleyen kullanıcı eylemini yakalayın. Bir kısıt sık sık başarısız oluyorsa UI'ya küçük bir ipucu veya ekstra istemci kontrolleri ekleyin. Ani bir artış yanıltıcı bir ekranın veya bozuk bir entegrasyonun işareti olabilir.

Örnek: zaman içinde temiz kalan bir dahili sipariş formu

Satış ve destek tarafından kullanılan basit bir “Sipariş Oluştur” aracını düşünün. Zararsız gibi görünür, ama veritabanınızdaki en önemli tablolarla etkileşir. Form bir kez kötü veri kabul ederse, bu hatalar faturalar, sevkiyat, iadeler ve raporlara yayılır.

Temiz yol, veritabanı kurallarının UI'yı yönlendirmesine izin vermektir. Form, kuralların geçerli kaldığı dost bir ön uç olur; birisi veri içe aktarsa veya başka yerden düzenleme yaparsa bile kurallar sürer.

Order tablosunun zorladığı bazı şeyler:

• Benzersiz sipariş numarası: her order_number farklı olmalı.
• Her zaman doğru kurallar için check'ler: quantity > 0, unit_price >= 0 ve belki unit_price <= 100000.
• Customer'a foreign key: her sipariş gerçek bir müşteri kaydına işaret etmeli.

Gerçek kullanımda ne olur bakalım.

Bir temsilci aklından bir sipariş numarası yazar ve yanlışlıkla birini tekrar kullanır. Kaydetme unique kısıtta başarısız olur. Belirsiz bir “kaydetme başarısız” yerine UI şöyle diyebilir: “Sipariş numarası zaten var. Bir sonraki kullanılabilir numarayı kullanın veya mevcut siparişi arayın.”

Daha sonra bir müşteri kaydı birleştirilir veya silinirken biri hâlâ formu açık tutuyor olabilir. Eski müşteri seçili halde Kaydet’e basarlar. Foreign key bunu engeller. İyi bir UI yanıtı: “Bu müşteri artık kullanılabilir değil. Müşteri listesini yenileyin ve başka birini seçin.” Sonra Müşteri dropdown'unu yeniden yükleyip formun geri kalanını korursunuz ki kullanıcı işini kaybetmesin.

Zamanla bu desen, herkesin her gün dikkatli olmasına güvenmeden siparişleri tutarlı tutar.

Karışık hatalara ve kirli veriye yol açan yaygın hatalar

En hızlı kirli veriye neden olan şey UI-only kurallara güvenmektir. Formdaki zorunlu alan yardımcı olur, ama içe aktarımlar, entegrasyonlar, yönetici düzenlemeleri veya aynı tabloya yazan ikinci bir ekranı korumaz. Eğer veritabanı kötü değerleri kabul ediyorsa, bunlar ileride her yerde ortaya çıkar.

Bir diğer yaygın hata, gerçekte çok katı kısıtlar yazmaktır. Bir check ilk gün doğru gelebilir ama bir hafta sonra normal kullanım durumlarını engeller (iade işlemleri, kısmi sevkiyatlar veya başka ülkelerin telefon numaraları gibi). İyi bir kural: daima doğru olması gerekenleri kısıtlayın, genellikle doğru olanları değil.

Güncellemeler sık sık gözden kaçırılır. Düzenleme sırasında unique çakışmaları klasik bir hatadır: kullanıcı bir kaydı açar, alakasız bir alanı değiştirir ve kaydetme başarısız olur çünkü aynı unique değeri başka bir yerde değişmiştir. Durum geçişleri başka bir tuzak olabilir. Bir kayıt Draft'tan Approved'a sonra Cancelled'a geçebiliyorsa, check'ler tüm geçiş yolunu izin verecek şekilde düşünülmelidir.

Yabancı anahtarlar en çok önlenebilir şekilde başarısız olur: kullanıcıların ID yazmasına izin vermek. UI ilişki için serbest metin izin verirse kırık ilişkiler elde edersiniz. İlişkiler için seçicileri tercih edin ve veritabanındaki FK'yi son gard olarak tutun.

Son olarak, ham veritabanı hataları panik ve destek taleplerine yol açar. Katı kısıtları korurken yine de insana yönelik mesajlar gösterebilirsiniz.

Kısa düzeltme listesi:

• Kısıtları tek kaynak olarak tutun, sadece form kuralları olarak değil
• Kontrolleri gerçek iş akışlarına göre, istisnaları da düşünerek tasarlayın
• Yalnızca “oluştur”u değil, düzenlemeleri ve geçişleri de ele alın
• İlişkiler için ID yazdırmayın; seçiciler kullanın
• Kısıt hatalarını kullanıcı dostu, alan düzeyinde mesajlara eşleyin

Kodsuz ekipler için hızlı kontrol listesi ve sonraki adımlar

Formu göndermeden önce, aceleyle, kötü bir günde ve kopyalanmış verilerle kullanılacağını varsayın. En güvenli yaklaşım form doğrulaması için veritabanı kısıtlarıdır; böylece UI bir şeyi kaçırsa bile veritabanı gerçeği uygular.

Yayına almadan önce hızlı kontroller

Her veritabanına yazan form için şu kontrolleri çalıştırın:

• Çoğaltmalar: hangi alanların benzersiz olması gerektiğini belirleyin (e-posta, sipariş numarası, dış ID) ve unique kuralının varlığını doğrulayın
• Eksik ilişkiler: her zorunlu ilişkinin (ör. bir Order'ın bir Customer'a sahip olması) uygulandığını doğrulayın
• Geçersiz aralıklar: sınır içinde kalması gereken değerler için check ekleyin (miktar > 0, indirim 0 ile 100 arası)
• Zorunlu alanlar: “olmazsa olmaz” veriyi sadece UI zorunlu işaretleriyle değil, veritabanı seviyesinde zorunlu kılın
• Güvenli varsayılanlar: otomatik doldurulması gerekenleri belirleyin (status = "Draft") ki insanlar tahmin etmesin

Sonra kullanıcı gibi test edin, yapıcı gibi değil: bir temiz gönderim yapın, sonra kopyalar, eksik ilişkiler, aralık dışı sayılar, boş zorunlu alanlar ve yanlış tür girişlerle kırmaya çalışın.

AppMaster'da sonraki adımlar

AppMaster (appmaster.io) üzerinde inşa ediyorsanız, önce Data Designer'da kuralları modelleyin (unique, check, foreign key), sonra web veya mobil UI editörde formu oluşturun ve Business Process Editor ile kaydetme mantığını bağlayın. Bir kısıt başarısız olduğunda hatayı yakalayın ve onu bir net eyleme eşleyin: neyi değiştirmeli ve nerede.

Hata metinlerini sakin ve tutarlı tutun. Suçlayıcı ifadelerden kaçının. “Benzersiz bir e-posta adresi kullanın” demeyi tercih edin, “E-posta geçersiz” demek yerine. Mümkünse çakışan değeri veya gerekli aralığı gösterin ki düzeltme bariz olsun.

Bir gerçek form seçin (ör. “Müşteri Oluştur” veya “Yeni Sipariş”), baştan sona inşa edin ve ekipten gelen karışık örnek verilerle kırmayı deneyin.