Müşteri 3.000 ürünlük bir dosya gönderdi. Yükleme başladı, 1.400. satırda hata verdi ve durdu. Şimdi hangi ürünlerin eklendiği, hangilerinin eklenmediği belli değil ve dosyayı baştan yüklemek çift kayıt üretecek.
Bu yazı, toplu içe aktarmayı güvenli yapmayı ele alıyor.
CSV'nin Görünmeyen Zorlukları
Basit görünen bu biçim çok sayıda tuzak barındırır:
- Ayırıcı karakter değişebilir. Virgül veya noktalı virgül.
- Karakter kodlaması belirsizdir.
- Hücre içinde satır sonu olabilir.
- Sayı biçimleri farklıdır. Ondalık ayırıcı.
- Baştaki sıfırlar kaybolur.
Beşinci madde Türkiye'de sık yaşanan bir veri kaybıdır: telefon numaraları ve barkod kodları elektronik tabloda sayı olarak algılanır ve baştaki sıfırlar silinir — dosya kaydedildiğinde o sıfırlar kalıcı olarak kaybolmuştur.
Bu kayıp yükleme sırasında değil, dosyanın hazırlanması sırasında olur ve fark edilmez.
Birinci madde ise bölgesel ayarlardan kaynaklanır. Türkçe ayarlı bir sistemde kaydedilen dosya noktalı virgül kullanabilir.
Üçüncü madde ise naif satır bazlı okuma yapan kodları bozar.
İki Aşamalı Yaklaşım
Doğru desen doğrulama ile yazmayı ayırmaktır:
- Dosyanın tamamını okuyup doğrulayın.
- Tüm hataları toplayın.
- Kullanıcıya rapor gösterin.
- Onay alınca yazmaya başlayın.
İkinci madde deneyimi tamamen değiştirir: ilk hatada durup "satır 14 hatalı" demek yerine tüm hataları birden listelemek, kullanıcının dosyayı tek seferde düzeltmesini sağlar — aksi hâlde 40 kez yükleyip düzeltmek zorunda kalır.
Bu, en çok şikayet üreten davranışlardan biridir.
Dördüncü madde ise kısmi yazmayı önler. Doğrulama geçmeden hiçbir kayıt oluşturulmaz.
Üçüncü madde ise önizleme fırsatı da sunar; kaç kayıt eklenecek, kaçı güncellenecek önceden gösterilebilir.
Kısmi Başarısızlık
| Politika | Uygunluk |
|---|---|
| Hepsi ya da hiçbiri | Tutarlılık kritikse |
| Geçerli olanları al | Büyük dosyalarda pratik |
| İlk hatada dur | Genellikle kötü |
Üçüncü satır başta anlatılan sorunu üretir: yarıda kesilen bir içe aktarma, hangi kayıtların işlendiğini belirsiz bırakır ve dosyayı tekrar yüklemek çift kayıt riski taşır.
Bu politika kullanılacaksa mutlaka nereye kadar işlendiği kaydedilmelidir.
İkinci satır büyük dosyalarda tercih edilir ama net raporlama gerektirir; kullanıcı hangi satırların atlandığını bilmelidir.
Birinci satır ise işlem kullanarak sağlanır ve tutarlılık açısından en güvenlidir.
Tekrar Yüklemeye Dayanıklılık
Aynı dosyanın iki kez yüklenmesi kaçınılmazdır:
- Her satır için benzersiz bir anahtar belirleyin.
- Varsa güncelleyin, yoksa ekleyin.
- Böylece tekrar zararsız olur.
Bu desen sorunu kökten çözer: ürün kodu gibi benzersiz bir alan üzerinden "varsa güncelle, yoksa ekle" mantığı kurmak, aynı dosyanın on kez yüklenmesini bile zararsız hâle getirir.
Kullanıcı bir hata olduğunda düzeltip yeniden yükleyebilir; çift kayıt oluşmaz.
Bu yaklaşım aynı zamanda düzenli veri güncellemesi için de kullanılabilir. Aynı dosya her hafta yüklenerek fiyatlar güncellenir.
Benzersiz anahtar dosyada yoksa, kullanıcıdan hangi sütunun anahtar olduğunu seçmesi istenmelidir.
Büyük Dosyalar
Bellek ve süre sınırları devreye girer:
- Dosyayı satır satır okuyun.
- Tamamını belleğe almayın.
- Toplu ekleme kullanın.
- Uzun işlemleri arka plana alın.
Üçüncü madde performansı dramatik biçimde artırır: her satır için ayrı bir ekleme sorgusu çalıştırmak yerine yüzer satırlık gruplar hâlinde eklemek, aynı işi kat kat hızlı tamamlar.
Binlerce ayrı sorgu, ağ ve işlem yükü açısından çok pahalıdır.
Dördüncü madde ise web isteği sınırlarını aşar. Büyük dosyalar bir kuyruğa alınıp arka planda işlenmeli, kullanıcıya ilerleme gösterilmelidir.
İkinci madde ise paylaşımlı hostingde zorunludur; büyük bir dosyayı tamamen belleğe okumak bellek sınırını aşar.
Hata Raporu Tasarımı
| Bilgi | Neden |
|---|---|
| Satır numarası | Dosyada bulmak için |
| Sütun adı | Hangi alan hatalı |
| Girilen değer | Neyin sorun olduğunu görmek |
| Beklenen biçim | Nasıl düzeltileceği |
| İndirilebilir hata dosyası | Büyük dosyalarda şart |
Beşinci satır büyük dosyalarda zorunludur: 400 hatalı satırı ekranda listelemek kimseye yardımcı olmaz — hataları içeren bir dosya indirtmek, kullanıcının kendi tablosunda düzeltme yapmasını sağlar.
Bu dosya, orijinal satırlara ek olarak bir hata açıklaması sütunu içermelidir.
Dördüncü satır ise destek yükünü azaltır. "Geçersiz tarih" yerine "tarih GG.AA.YYYY biçiminde olmalı" demek, kullanıcının kendi çözmesini sağlar.
Şablon Sunmak
En etkili önlem, hataları baştan engellemektir:
- İndirilebilir örnek dosya verin.
- Sütun başlıklarını sabitleyin.
- Örnek satır ekleyin.
- Zorunlu alanları belirtin.
Üçüncü madde en çok işe yarayan detaydır: şablonda doldurulmuş bir örnek satır bulunması, kullanıcının her alanın hangi biçimde olması gerektiğini açıklama okumadan anlamasını sağlar.
Boş bir şablon, tarih ve sayı biçimlerinde tahmine yol açar.
İkinci madde ise sütun eşleştirme sorununu ortadan kaldırır. Kullanıcı sütunları kendi adlandırırsa, hangi sütunun ne olduğunu eşleştirmek gerekir.
Alternatif olarak esnek bir eşleştirme ekranı sunulabilir ama bu ek karmaşıklıktır.
Güvenlik Notu
Yüklenen dosyalar güvenilmez veridir:
- Dosya boyutunu sınırlayın.
- Satır sayısını sınırlayın.
- İçeriği doğrulayın.
- Formül enjeksiyonuna dikkat edin.
Dördüncü madde az bilinen ama gerçek bir risktir: dışa aktardığınız bir dosyada eşittir işaretiyle başlayan bir hücre, elektronik tablo programında formül olarak çalıştırılabilir — bu, kullanıcının bilgisayarında komut çalıştırmaya kadar gidebilir.
Bu nedenle dışa aktarırken formül karakteriyle başlayan hücrelerin başına bir kaçış karakteri eklenmelidir.
İkinci madde ise kaynak korumasıdır. Milyon satırlık bir dosya, sunucunuzu uzun süre meşgul eder.
Büyük dosya yüklemeleri için PHP sınırlarınızın yeterli olması gerekir; Linux hosting çözüm paketleri içinde yükleme boyutu ve çalışma süresi ayarları panelden düzenlenebilir.
Sonuç
Toplu içe aktarmada en çok şikayet üreten davranış ilk hatada durmaktır: "satır 14 hatalı" deyip durmak, kullanıcının dosyayı 40 kez yükleyip düzeltmesine yol açar — tüm hataları toplayıp tek raporda gösterin. Yazmadan önce dosyanın tamamını doğrulayın ve benzersiz bir anahtar üzerinden "varsa güncelle, yoksa ekle" mantığı kurun; böylece aynı dosyanın on kez yüklenmesi bile zararsız olur. Baştaki sıfırların kaybolduğunu da unutmayın.
Sıkça Sorulan Sorular (SSS)
Hataları nasıl raporlamalıyım?
Tümünü birden toplayıp tek raporda gösterin — ilk hatada durmak kullanıcıyı dosyayı defalarca yüklemeye zorlar. Raporda satır numarası, sütun adı, girilen değer ve beklenen biçim bulunsun. Büyük dosyalarda hataları içeren indirilebilir bir dosya sunmak şarttır; 400 satırı ekranda listelemek işe yaramaz.
Aynı dosya iki kez yüklenirse ne olur?
Önlem almazsanız çift kayıt oluşur. Ürün kodu gibi benzersiz bir alan üzerinden "varsa güncelle, yoksa ekle" mantığı kurun; bu, aynı dosyanın on kez yüklenmesini bile zararsız hâle getirir ve düzenli veri güncellemesi için de kullanılabilir.
Telefon numaralarındaki baştaki sıfırlar neden kayboluyor?
Elektronik tablo programı o alanları sayı olarak algılar ve baştaki sıfırları siler. Bu kayıp yükleme sırasında değil, dosyanın hazırlanması sırasında olur ve fark edilmez. Şablonunuzda bu alanların metin olarak biçimlendirilmesi gerektiğini belirtin.
Büyük dosyalarda ne yapmalıyım?
Dosyayı satır satır okuyun, tamamını belleğe almayın. Her satır için ayrı sorgu yerine yüzer satırlık gruplar hâlinde ekleyin — aynı işi kat kat hızlı tamamlar. Çok büyük dosyaları bir kuyruğa alıp arka planda işleyin ve kullanıcıya ilerleme gösterin.
