CSV/Excel/JSON içe/dışa aktarmalarını, net hata doğrulamasını, roller ve denetim kayıtlarını destekleyen güvenilir bir web uygulaması nasıl tasarlanır öğrenin.
Ekranları tasarlamadan veya bir dosya ayrıştırıcı seçmeden önce, veriyi kimlerin ürününüze taşıdığını ve neden taşıdıklarını netleştirin. İç kullanıcılara yönelik bir veri içe aktarma uygulaması, müşterilerin kullandığı kendi kendine hizmet Excel içe aktarma aracından çok farklı görünecektir.
İçe/dışa aktarmalara dokunacak rolleri listeleyerek başlayın:
Her rol için beklenen beceri düzeyini ve karmaşıklık toleransını tanımlayın. Müşteriler genellikle daha az seçenek ve ürün içi daha iyi açıklamalar ister.
En önemli senaryolarınızı yazın ve önceliklendirin. Yaygın olanlar:
Sonra ölçülebilir başarı metriklerini tanımlayın. Örnekler: daha az başarısız içe aktarma, hataların çözüm süresinin kısalması, “dosyam yüklenmiyor” destek taleplerinde azalma. Bu metrikler, daha sonra yapılacak takaslarda (ör. daha net hata raporlama mı yoksa daha fazla dosya formatına yatırım mı) yol gösterir.
Gün 1’de destekleyeceklerinizi açıkça belirtin:
Son olarak, dosyaların KİB içerip içermediğini, saklama gereksinimlerini (yüklemeleri ne kadar süre saklayacağınız) ve denetim gereksinimlerini erken tespit edin. Bu kararlar depolama, kayıt tutma ve izinleri tüm sistemde etkiler.
Süslü bir sütun eşleme UI’si veya CSV doğrulama kuralları hakkında düşünmeden önce, ekibinizin teslim edebileceği ve işletmekten çekinmeyeceği bir mimari seçin. İçe/dışa aktarmalar genellikle “sıkıcı” altyapıdır—yenilikten çok yineleme hızı ve hata ayıklama kolaylığı öne çıkar.
Her ana akım web yığını bir veri içe aktarma uygulamasını çalıştırabilir. Seçiminizi mevcut becerilere ve işe alım gerçeklerine göre yapın:
Önemli olan tutarlılıktır: yığın, yeni içe aktarma türleri, yeni doğrulama kuralları ve yeni dışa aktarma formatları eklemeyi yeniden yazmadan kolaylaştırmalı.
Eğer tek seferlik prototipe bağlı kalmadan hızla iskelet oluşturmak istiyorsanız, Koder.ai gibi sohbet tabanlı bir kod üretme platformu yardımcı olabilir: içe aktarma akışınızı (yükleme → önizleme → eşleme → doğrulama → arka plan işleme → geçmiş) tarif ederek React UI ve Go + PostgreSQL backend üretebilir, planlama modu ve snapshot/rollback ile hızlı yineleme yapabilirsiniz.
Yapılandırılmış kayıtlar, upsert'ler ve veri değişiklikleri için ilişkisel veritabanı (Postgres/MySQL) kullanın.
Orijinal yüklemeleri (CSV/Excel) object storage (S3/GCS/Azure Blob) içinde saklayın. Ham dosyaları tutmak destek için paha biçilemezdir: ayrıştırma sorunlarını yeniden üretir, işleri tekrar çalıştırır ve hata işleme kararlarını açıklamanıza yardımcı olur.
Küçük dosyalar senkron (yükleme → doğrula → uygula) olarak çalışabilir ve hızlı bir kullanıcı deneyimi sağlar. Daha büyük dosyalar için işi arka plan işlerine taşıyın:
Bu, yeniden denemeler ve hız sınırlı yazma için de hazır olmanızı sağlar.
SaaS inşa ediyorsanız, tenant verilerini (satır düzeyinde kapsam, ayrı şemalar veya ayrı veritabanları) nasıl ayıracağınıza erken karar verin. Bu seçim veri dışa aktarma API’nizi, izinleri ve performansı etkiler.
Çalışma süresi hedefleri, maksimum dosya boyutu, bir içe aktarmadaki beklenen satır sayısı, tamamlanma süresi ve maliyet sınırlarını yazın. Bu sayılar iş kuyruğu seçimini, partileme stratejisini ve indekslemeyi UI’yi cilalamadan çok önce yönlendirir.
Kabul akışı her içe aktarmanın tonunu belirler. Eğer tahmin edilebilir ve affedici hissediyorsa, bir şeyler ters gittiğinde kullanıcılar tekrar deneyecektir—destek talepleri azalır.
Web UI için sürükle-bırak alanı ve klasik dosya seçimci sunun. Sürükle-bırak güç kullanıcılar için daha hızlıdır; dosya seçimci daha erişilebilir ve tanıdıktır.
Müşterileriniz verilerini başka sistemlerden alıyorsa bir API uç noktası da ekleyin. Bu multipart yüklemeleri (dosya + meta) kabul edebilir veya büyük dosyalar için ön-imzalı URL akışı kullanabilirsiniz.
Yüklemede, veriyi commit etmeden hafif bir ayrıştırma yaparak bir “önizleme” oluşturun:
Bu önizleme, sonraki adımlarda sütun eşleme ve doğrulama için temel olur.
Orijinal dosyayı güvenli şekilde (object storage tipik) her zaman saklayın. Bunu değiştirilemez tutun, böylece:
Her yüklemeyi ilk sınıf bir kayıt olarak ele alın. Yükleyen, zaman damgası, kaynak sistem, dosya adı ve checksum gibi meta verileri kaydedin (çoğaltmaları tespit etmek ve bütünlük sağlamak için). Bu, denetlenebilirlik ve hata ayıklama için değer taşır.
Hızlı ön kontrolleri hemen çalıştırın ve gerekirse erken başarısız olun:
Ön kontrol başarısızsa, kullanıcılara net bir mesaj dönün ve neyi düzeltmeleri gerektiğini gösterin. Hedef, gerçekten kötü dosyaları hızlıca durdurmak; daha sonra eşlenebilecek ve temizlenebilecek geçerli ama kusurlu verileri engellememektir.
Çoğu içe aktarma hatası, dosyanın başlıklarının uygulamanızın alanlarıyla eşleşmemesinden kaynaklanır. Net bir sütun eşleme adımı “dağınık CSV”yi tahmin edilebilir girdiye çevirir ve kullanıcıları deneme-yanılma döngüsünden kurtarır.
Basit bir tablo gösterin: Kaynak sütun → Hedef alan. Olası eşlemeleri otomatik algılayın (büyük/küçük harfe duyarsız başlık eşleştirme, “E-mail” → email gibi eşanlamlılar), ancak kullanıcıların her zaman üzerine yazmasına izin verin.
Bazı kullanılabilirlik dokunuşları ekleyin:
Müşteriler aynı formatı her hafta içe aktarıyorsa, tek tıkla bunu sağlayın. Şablonları şu kapsamlarda kaydetmelerine izin verin:
Yeni bir dosya yüklendiğinde sütun örtüşmesine göre bir şablon önerin. Ayrıca versiyonlamayı destekleyin ki kullanıcılar bir şablonu güncelleyip eski çalışmaları bozmasın.
Her eşlenen alan için uygulanabilecek hafif dönüşümler ekleyin:
UI’da dönüşümlerin açıkça gösterilmesini sağlayın (“Uygulandı: Trim → Parse Date”) ki çıktı izah edilebilir olsun.
Tam dosyayı işlemeye başlamadan önce (ör. 20 satır için) eşlenmiş sonuçların önizlemesini gösterin. Orijinal değeri, dönüşmüş değeri ve uyarıları (ör. “Tarih ayrıştırılamadı”) gösterin. Burada kullanıcılar sorunları erken yakalar.
Kullanıcılardan bir anahtar alan (email, external_id, SKU) seçmelerini isteyin ve çoğaltmalarda ne olacağına dair açıklama yapın. Upsert’leri daha sonra işleseniz bile, bu adım beklentileri belirler: çoğalt anahtarları dosyada uyarı verir ve hangi kaydın “kazandığını” (ilk, son veya hata) önerir.
Doğrulama, “dosya yükleyici” ile kullanıcının güvenebileceği bir içe aktarma özelliği arasındaki farktır. Amaç, katı olmak için katılaşmak değil—kötü verinin yayılmasını önleyip kullanıcılara net, uygulanabilir geri bildirim vermektir.
Doğrulamayı üç ayrı kontrol olarak ele alın, her biri farklı amaç taşır:
email bir string mi?”, “amount bir sayı mı?”, “customer_id var mı?” Bu hızlıdır ve ayrıştırmadan hemen sonra çalıştırılabilir.country=US ise state zorunlu”, “end_date start_date’den sonra olmalı”, “Plan adı bu workspace’te var olmalı.” Bunlar genellikle bağlam (diğer sütunlar veya DB lookupları) gerektirir.Bu katmanları ayrı tutmak sistemi genişletmeyi ve UI’da açıklamayı kolaylaştırır.
Erken karar verin: bir içe aktarma:
Her ikisini de sunabilirsiniz: varsayılan olarak katı, yöneticiler için “kısmi içe aktarmaya izin ver” seçeneği gibi.
Her hata şu soruyu yanıtlamalı: ne oldu, nerede oldu ve nasıl düzeltilir?
Örnek: “Satır 42, ‘Start Date’ sütunu: YYYY-MM-DD formatında geçerli bir tarih olmalı.”
Ayrımı yapın:
Kullanıcılar nadiren her şeyi tek seferde düzeltir. Doğrulama sonuçlarını bir içe aktarma denemesine bağlayarak yeniden yüklemeyi kolaylaştırın. Bu işlemi toplu çözmek için indirilebilir hata raporlarıyla eşleştirin (aşağıda detaylandırılmıştır).
Pratik bir yaklaşım hibrittir:
Bu, doğrulamayı esnek tutarken onu hata ayıklaması zor bir “ayarlar labirentine” dönüştürmez.
İçe aktarmalar sık sık sıkıcı nedenlerle başarısız olur: yavaş DB, pik zamanlarda dosya dalgalanmaları veya tek bir “kötü” satır tüm iş akışını bloke edebilir. Güvenilirlik çoğunlukla ağır işi istek/yanıt yolundan çıkarmak ve her adımı tekrar güvenle çalıştırılabilir yapmakla ilgilidir.
Ayrıştırma, doğrulama ve yazma işlemlerini arka plan işleri (kuyruk/worker) içinde çalıştırın ki uploadlar web zaman aşımına takılmasın. Bu ayrıca müşteriler daha büyük tablolar içe aktarmaya başladığında işçi ölçeklendirmeyi mümkün kılar.
Pratik bir desen: işi parçalara bölün (ör. 1.000 satır/satır grubu). Bir “ebeveyn” import işi parça işlerini planlar, sonuçları toplar ve ilerlemeyi günceller.
Import’u bir durum makinesi olarak modelleyin ki UI ve operasyon ekibi her zaman ne olduğunu bilsin:
Her durum geçişi için zaman damgası ve deneme sayısı saklayın ki “ne zaman başladı?” ve “kaç deneme oldu?” gibi sorulara loglarda boğulmadan cevap verilebilsin.
İşlenmiş satır sayısı, kalan satırlar ve şu ana kadar bulunan hatalar gibi ölçülebilir ilerleme gösterin. Eğer throughput tahmini verebiliyorsanız kaba bir ETA ekleyin—tam bir geri sayımdan ziyade “~3 dk” gibi yaklaşık değerleri tercih edin.
Yeniden denemeler asla çoğaltma veya çift uygulama yaratmamalı. Yaygın teknikler:
Workspace başına eşzamanlı içe aktarmaları sınırlayın ve veritabanını ezmemek için yazma-ağır adımları (örn. saniyede maksimum N satır) hız sınırlayın.
İnsanlar neyin yanlış gittiğini anlayamazsa aynı dosyayı tekrar tekrar denerler. Her içe aktarmayı birinci sınıf “çalıştırma” olarak ele alın ve net bir iz kaydı ile uygulanabilir hatalar sunun.
Dosya gönderildiğinde hemen bir import run varlık kaydı oluşturun. Bu kayıt şunları içermeli:
Bu, import geçmişi ekranınız olur: durum, sayılar ve “detayları görüntüle” linkli basit bir çalıştırma listesi.
Uygulama logları mühendisler için iyidir; fakat kullanıcıların sorgulayabileceği yapılandırılmış hatalara ihtiyacı vardır. Hataları import run’a bağlı yapısal kayıtlar olarak saklayın, ideal olarak iki seviyede:
Bu yapı hızlı filtreleme ve haftalık “En çok görülen 3 hata tipi” gibi özetler üretmenize olanak verir.
Çalıştırma detayları sayfasında tip, sütun ve önem bazlı filtreler ve bir arama kutusu (örn. “email”) sağlayın. Ardından orijinal satırı ve error_columns, error_message gibi ekstra sütunları içeren indirilebilir CSV hata raporu sunun; “Tarih formatını YYYY-MM-DD olarak düzeltin” gibi açık yönergeler ekleyin.
“Dry run” modu, aynı eşleme ve kuralları kullanarak her şeyi doğrular ama veri yazmaz. İlk defa yapılan içe aktarmalar için idealdir ve kullanıcıların commit etmeden önce güvenle yineleme yapmasına izin verir.
Satırlar veritabanınıza indiğinde iş “tamam” gibi görünür—ama uzun vadeli maliyet genelde dağınık güncellemeler, çoğaltmalar ve belirsiz değişiklik geçmişinde çıkar. Bu bölüm, içe aktarmaların öngörülebilir, geri alınabilir ve açıklanabilir olmasını sağlayacak veri modelini tasarlamaya odaklanır.
Her varlık için içe aktarılan bir satırın domain modelinize nasıl eşleneceğini tanımlayın. Her varlık için içe aktarma şu işlemleri yapabilir mi:
Bu karar import kurulum UI’sında açıkça gösterilmeli ve davranış iş ile birlikte saklanmalıdır ki tekrar edilebilir olsun.
“Create or update” destekliyorsanız stabil upsert anahtarlarına ihtiyacınız var—aynı kaydı her defasında tanımlayan alanlar. Yaygın seçimler:
external_id (başka bir sistemden geliyorsa en iyisi)account_id + sku)Çakışma durumunda ne yapılacağını tanımlayın: iki satır aynı anahtarı paylaşıyorsa veya anahtar birden fazla kayıtla eşleşiyorsa ne olacak? İyi varsayılanlar “satırı açık bir hata ile başarısız kıl” veya “son satır kazanır” şeklindedir; bilinçli seçim yapın.
Tutarlılığı koruyan yerlerde transaction kullanın (örn. bir ebeveyn ve onun çocuklarını oluştururken). 200k satırlık bir dosya için tek büyük transaction kullanmaktan kaçının; tabloları kilitleyebilir ve yeniden denemeleri zorlaştırır. Bunun yerine parça yazma (ör. 500–2.000 satır) ve idempotent upsert’ler tercih edin.
Bir satır bir ebeveyn kayda referans veriyorsa (ör. Company), ya onun var olmasını zorunlu kılın ya da kontrollü bir adımda oluşturun. “Eksik ebeveyn” hatalarıyla erken başarısız olmak yarım bağlı veriyi önler.
İçe aktarma kaynaklı değişiklikler için denetim kayıtları ekleyin: kim import’u tetikledi, ne zaman, kaynak dosya, ve her kayıt için özet değişiklik (eski vs yeni). Bu destek işini kolaylaştırır, kullanıcı güveni sağlar ve rollbackleri basitleştirir.
Dışa aktarmalar basit görünür ama müşteriler bir teslim tarihinden hemen önce “her şeyi” indirmeye çalışınca sorun ortaya çıkar. Ölçeklenebilir bir dışa aktarma sistemi büyük veri setlerini uygulamanızı yavaşlatmadan veya tutarsız dosyalar üretmeden işlemelidir.
Üç seçenekle başlayın:
Artımlı dışa aktarmalar entegrasyonlar için özellikle faydalıdır ve tekrar eden tam dökümler yerine daha düşük yük sağlar.
Seçiminiz ne olursa olsun, tutarlı başlıklar ve stabil sütun sırası sağlayın ki downstream süreçler bozulmasın.
Büyük dışa aktarmalar tüm satırları belleğe yüklememeli. Satırları alırken yazmak için sayfalama/streaming kullanın. Bu zaman aşımını önler ve web uygulamanızı duyarlı tutar.
Büyük veri setleri için dışa aktarmaları arka plan işinde oluşturun ve hazır olduğunda kullanıcıyı bilgilendirin. Yaygın desen:
Bu, hata raporları ve içe aktarmalar için kullandığınız aynı “çalıştırma geçmişi + indirilebilir artefakt” desenleriyle iyi eşleşir.
Dışa aktarmalar sık sık denetlenir. Her zaman şunları dahil edin:
Bu ayrıntılar kafa karışıklığını azaltır ve güvenilir uzlaştırma sağlar.
İçe/dışa aktarmalar çok veri taşıyabildiği için güçlü bir güvenlik yüzeyi gerektirir. Bu aynı zamanda sıkça yapılan güvenlik hatalarının olduğu yerdir: fazla geniş rol, sızan dosya URL’si veya log’larda kazara kişisel veriler.
Uygulamanızdaki genel kimlik doğrulamayı kullanın—içe/dışa aktarmalar için özel bir auth yolu oluşturmayın.
Tarayıcı tabanlı kullanıcılar için oturum tabanlı auth (ve isteğe bağlı SSO/SAML) en uygun olabilir. Otomatikleştirilmiş importlar/entegre job’lar için API anahtarları veya OAuth token’ları, net kapsam ve rotasyon ile düşünülmelidir.
Pratik kural: import UI ve import API aynı izinleri uygulamalı, farklı kitleler tarafından kullanılsalar bile.
İçe/dışa aktarma yeteneklerini açık ayrı ayrı ayrıcalıklar olarak ele alın. Yaygın roller:
“Dosya indirme” iznini ayrı tutun. Birçok hassas sızıntı, biri run’ı görebiliyorken sistemin otomatik olarak indirme yetkisi verdiği varsayıldığı durumlarda olur.
Ayrıca satır/tenant düzey sınırlarını düşünün: bir kullanıcı yalnızca ait olduğu hesap/çalışma alanı için veri içe/dışa aktarmalı.
Saklanan dosyalar (yüklemeler, oluşturulan hata CSV’leri, dışa aktarma arşivleri) için özel object storage ve kısa ömürlü indirme linkleri kullanın. Uyumluluk gerekiyorsa dinlenme halindeyken şifreleme kullanın ve tutarlı olun: orijinal yükleme, işlenmiş ara dosya ve üretilen raporlar aynı kuralları takip etmelidir.
Log’lara dikkat edin. Hassas alanları (e-postalar, telefon numaraları, kimlikler, adresler) maskeleyin ve ham satırları varsayılan olarak loglamayın. Gerekirse hata ayıklamada “detaylı satır loglamayı” sadece yöneticiler için bir ayar arkasına alın ve süreli temizlenmesini sağlayın.
Her yüklemeyi doğrulanmamış girdi olarak değerlendirin:
Ayrıca yapıyı erken doğrulayın: bariz bozuk dosyaları arka plan işlerine ulaşmadan reddedin ve kullanıcıya neyin yanlış olduğunu açıkça bildirin.
Soruşturma esnasında gereken olayları kaydedin: kim dosya yükledi, kim import başlattı, kim dışa aktarma indirdi, izin değişiklikleri ve başarısız erişim girişimleri.
Denetim girdileri actor, zaman damgası, workspace/tenant ve etkilenen nesneyi (import run ID, export ID) içermeli, hassas satır verilerini saklamamalıdır. Bu, import geçmiş UI’siyle iyi çalışır ve “kim ne zaman neyi değiştirdi?” sorusuna hızlı cevap verir.
İçe/dışa aktarmalar müşteri verisine dokunuyorsa er ya da geç uç durumlarla karşılaşırsınız: garip kodlamalar, birleştirilmiş hücreler, yarım dolu satırlar, çoğaltmalar ve “dün çalışıyordu” gizemleri. İşletilebilirlik bu sorunların destek kabusuna dönüşmesini engeller.
En çok hata veren bölümlere odaklanan testlerle başlayın: ayrıştırma, eşleme ve doğrulama.
Sonra en az bir uçtan uca test ekleyin: upload → arka plan işleme → rapor üretimi. Bu testler UI, API ve worker’lar arasındaki sözleşme uyuşmazlıklarını yakalar.
Kullanıcı etkisini yansıtan sinyalleri izleyin:
Uyarıları semptomlara (artmış hata oranı, büyüyen kuyruk) bağlayın; her exception için alarm kurmak yerine gerçek kullanıcı etkisini hedefleyin.
İç ekiplerin işleri yeniden çalıştırması, takılı içe aktarmaları iptal etmesi ve hataları incelemesi için küçük bir admin yüzeyi sağlayın (giriş dosyası meta verisi, kullanılan eşleme, hata özeti ve log/trace bağlantıları).
Kullanıcılar için önlenebilir hataları azaltmak adına inline ipuçları, indirilebilir örnek şablonlar ve hata ekranlarında net sonraki adımlar sağlayın. İçe aktarma UI’sından merkezi bir yardım sayfasına (örn. /docs) link verin.
İçe/dışa aktarma sistemi "prod'a gönder" ile bitmez. Bunu güvenli varsayılanlar, net kurtarma yolları ve gelişmeye alan bırakan bir ürün özelliği olarak ele alın.
Geliştirme/staging/üretim için ayrı ortamlar kurun ve yüklenen dosyalar ile oluşturulan dışa aktarmalar için ayrı object storage bucket’ları (veya prefix’leri) kullanın. Her ortam için farklı şifreleme anahtarları ve kimlik bilgileri kullanın ve arka plan işçilerinin doğru kuyruğa işaret ettiğinden emin olun.
Staging, production ile aynısını yansıtmalı: aynı iş eşzamanlılığı, zaman aşımı ve dosya boyutu limitleri. Performans ve izinleri gerçek müşteri verisi riski olmadan burada doğrulayın.
İçe aktarmalar "sonsuz" yaşama eğilimindedir çünkü müşteriler eski spreadsheet’leri tutar. DB migrasyonlarını olağan şekilde kullanın, ancak import şablonlarını versiyonlayın ki bir şema değişikliği geçen çeyreğin CSV’sini bozmasın.
Pratik yaklaşım: her import run ile template_version saklayın ve eski sürümler için uyumluluk kodunu, deprecate edene kadar koruyun.
Değişiklikleri güvenle göndermek için feature flag kullanın:
Bayraklar, değişiklikleri önce dahili kullanıcılarda veya küçük müşteri gruplarında test etmenizi sağlar.
Destek ekibinin hataları nasıl inceleyeceğini belgeleyin: import geçmişi, iş ID’leri ve log’lar kullanılarak bir kontrol listesi: şablon versiyonunu doğrula, ilk hatalı satırı incele, storage erişimini kontrol et, sonra worker log’larına bak. Bu kontrol listesini dahili runbook’unuza ve uygun yerlerde admin UI’ye bağlayın (örn. /admin/imports).
Çekirdek akış kararlı hale geldikten sonra onu yüklemelerin ötesine genişletin:
Bu gelişmeler manuel işi azaltır ve veri içe aktarma web uygulamanızın müşterilerin mevcut süreçlerinde doğal hissetmesini sağlar.
Eğer bunu bir ürün özelliği olarak inşa ediyorsanız ve “ilk kullanılabilir sürüm” zamanını kısaltmak istiyorsanız, Koder.ai kullanarak import sihirbazı, iş durum sayfaları ve çalıştırma geçmişi ekranlarını uçtan uca prototiplemeyi, sonra kaynak kodunu geleneksel mühendislik iş akışına aktarmayı düşünebilirsiniz. Bu yaklaşım, ilk günün mükemmel UI tasarımından çok güvenilirlik ve yineleme hızını önemsediğiniz durumlarda özellikle pratiktir.
Öncelikle kimi içe/dışa aktarım yapacağını (yöneticiler, operatörler, müşteriler) ve başlıca kullanım durumlarını (onboarding sırasında toplu yükleme, periyodik senkronizasyon, tek seferlik dışa aktarma) netleştirin.
Gün 1 kısıtlarını yazın:
Bu kararlar mimariyi, UI karmaşıklığını ve destek yükünü şekillendirir.
Dosyalar küçükse ve doğrulama + yazma işlemleri web isteği zaman aşımı içinde güvenli şekilde tamamlanıyorsa senkron işleme kullanın.
Arka plan işleri kullanın when:
Yaygın desen: upload → kuyruğa al → çalıştırma durumu/ilerleme göster → tamamlandığında bildirim gönder.
Her iki şeyi de saklayın, farklı amaçlar için:
Ham yüklemeyi değiştirilemez tutun ve bir import run kaydıyla ilişkilendirin.
Herhangi bir şeyi kalıcı hale getirmeden önce başlıkları algılayan ve küçük bir örneği (ör. 20–100 satır) parse eden bir önizleme adımı oluşturun.
Yaygın değişkenlikleri ele alın:
Gerçek engelleyicilerde hızlıca başarısız olun (okunamayan dosya, eksik zorunlu sütunlar), ancak daha sonra eşlenebilecek veya dönüştürülebilecek verileri reddetmeyin.
Basit bir eşleme tablosu kullanın: Kaynak sütun → Hedef alan.
En iyi uygulamalar:
Her zaman tam dosyayı işlemeye başlamadan önce eşlenmiş bir önizleme gösterin.
Dönüşümleri hafif tutun ve kullanıcıya ne yapıldığını açıkça gösterin:
ACTIVE)Önizlemede “orijinal → dönüşmüş” gösterin ve dönüşüm uygulanamazsa uyarıları belirginleştirin.
Doğrulamayı katmanlara ayırın:
UI’da satır/sütun referanslı, düzeltilebilir mesajlar sağlayın (ör. “Satır 42, Start Date: YYYY-MM-DD olmalı”).
İçe aktarımların (tüm dosya başarısız olur) mı yoksa (geçerli satırlar kabul edilir) mi olacağını belirleyin; yöneticiler için her ikisini de sunmayı düşünün.
İşlemleri yeniden denemeye uygun hale getirin:
import_id + row_number veya satır hash'i)external_id) ve hep "insert" yapmayınBir dosya sunulduğunda hemen bir import run kaydı oluşturun ve yapılandırılmış, sorgulanabilir hatalar saklayın—sadece uygulama logları değil.
Kullanışlı hata özellikleri:
İçe/dışa aktarma güçlü olduğu kadar risklidir—yanlış izin, sızmış dosya URL’si veya log’larda hassas veriler gibi.
Gerekli kontroller:
KİB varsa, saklama ve silme kurallarını erken belirleyin.
Ayrıca her workspace için eşzamanlı içe aktarma sayısını sınırlayarak veritabanını koruyun.
Bu, kullanıcıların aynı dosyayı defalarca denemesi yerine sorunları düzeltmesini sağlar.