## CSV İçe Aktarma
#### PHP PDO · MySQL · AJAX · DataTables · Bootstrap 5 · Çılgın Yazılım Tasarım Kalıbı
**İçe aktarmadan önce ne olacağını göster; sonra ya hepsini yaz ya da sadece temizleri.**
[](https://php.net)
[](https://mysql.com)
[](https://getbootstrap.com)
[](https://datatables.net)
[](LICENSE)
**🇹🇷 Türkçe** · [🇬🇧 English](README.en.md)
[**▶ Canlı Demo**](https://cilginyazilim.com/kutuphane/uygulama/PHP-MySQL-CSV-Import-Ice-Aktarma-PDO-Ajax-DataTables-main/) · [Kaynak Kütüphanesi](https://cilginyazilim.com/kutuphane/php-csv-import) · [cilginyazilim.com](https://cilginyazilim.com)
---
### Canlı Demo
**Kurulum yok, kayıt yok, indirme yok — tarayıcınızdan 3 saniyede deneyin.**
▲ Görsele tıklayarak demoyu açabilirsiniz
**Üç modal:**
| Modal | Açılış | İçerik |
|-------|--------|--------|
| 👁 **Kişi detayı** | Kişi tablosundaki göz butonu | Alanların tam hâli + geldiği içe aktarmanın künyesi + paylaşılabilir `#kisi-4` bağlantısı |
| 👁 **İçe aktarma detayı** | Geçmiş tablosundaki göz butonu | Satır sayaçları, mod, dedupe politikası, süre, "bu aktarmanın kişilerini göster" |
| 🗑 **Silme onayı** | Çöp kutusu butonu | Neyin silineceği + **"bu e-posta yeniden aktarılabilir hâle gelir"** uyarısı |
---
### Dört Kritik Karar
#### 1) Dry-run: yazmadan önce göstermek
İçe aktarma ekranlarının klasik kusuru, kullanıcıyı **karanlıkta karar vermeye** zorlamasıdır. "Yükle" düğmesine basana kadar dosyanın kaç satırının bozuk olduğu bilinmez; basıldıktan sonra da geri dönüş yoktur.
`preview` uç noktası dosyanın tamamını `commit` ile **birebir aynı** kodla (`validate_row()`) işler, ama tek bir `INSERT` çalıştırmaz:
```php
// handle_preview() — hiçbir yazma yok, yalnızca sayım
$summary = ['total' => 0, 'ok' => 0, 'warning' => 0,
'error' => 0, 'dupe_file' => 0, 'dupe_db' => 0];
```
Bu simetri şart: önizleme ayrı bir doğrulama kodu kullansaydı, zamanla ikisi ayrışır ve "önizlemede temizdi ama aktarırken patladı" durumu doğardı. **Önizleme, aktarmanın kuru çalıştırılmasıdır** — taklidi değil.
#### 2) Hata ile uyarı ayrımı
Her kusuru hataya çevirmek kolaydır ama pahalıdır: %2'lik kirli veri yüzünden %98'lik temiz veriyi de reddetmek demektir.
```php
// Ad yoksa satır YAZILAMAZ → hata
if (mb_strlen($name) < 2) {
return ['data' => [], 'error' => 'Ad en az 2 karakter olmalı', ...];
}
// Telefon tuhafsa satır yine de değerlidir → uyarı
if (strlen($digits) !== 10) {
return [$digits, 'Telefon 10 hane değil (yine de kaydedilecek)'];
}
```
Kural şu: **kaydın kimliğini** kuran alanlar (ad, e-posta) eksikse satır reddedilir; **kaydı zenginleştiren** alanlar (telefon, şehir) kusurluysa satır girer ve kullanıcı uyarılır.
#### 3) Tekrarın üç farklı anlamı
"Bu e-posta zaten var" cümlesi üç ayrı duruma karşılık gelir ve üçünün de çözümü farklıdır:
| Durum | Ne demek? | Ne yapılır? |
|-------|-----------|-------------|
| `dupe_file` | Aynı e-posta **dosya içinde** iki kez geçiyor | İlk görülen kazanır; ikincisi atlanır ve raporlanır |
| `dupe_db` + `dedupe=skip` | Kayıt **veritabanında** zaten var | Mevcut kayda dokunulmaz; var olan veri kaynak sayılır |
| `dupe_db` + `dedupe=update` | Kayıt var, ama **CSV daha güncel** | Mevcut kayıt CSV ile tazelenir; dosya kaynak sayılır |
Son satır bir tercih değil, **verinin kime ait olduğuyla** ilgili bir karardır: telefon güncelleme dosyasında CSV haklıdır, müşteri listesi eklemede veritabanı haklıdır. Bu yüzden seçim kullanıcıya bırakılır ve önizleme, seçim değiştiğinde **anında yeniden hesaplanır**.
Ama asıl koruma uygulama kodunda değil, **veritabanı kısıtındadır**:
```sql
UNIQUE KEY `uq_contacts_email` (`email`)
```
"Önce `SELECT`, yoksa `INSERT`" kontrolü iki eşzamanlı istekte yarışır ve kaybeder; `UNIQUE` indeks kaybetmez. Kod yine de önce `SELECT` yapar — ama bunu **önizleme için** yapar. Yazma anındaki gerçek koruma indeksin kendisidir ve yarış durumunda dönen hata **indeks adına bakılarak** ayırt edilir:
```php
$isDupeEmail = $ex->getCode() === '23000'
&& str_contains($ex->getMessage(), 'uq_contacts_email');
if (!$isDupeEmail) {
throw $ex; // başka bir kısıt ihlali — yanlış mesajla gizleme
}
```
#### 4) Künye ve kayıtlar aynı transaction'da
`import_runs` satırı, kişilerle **aynı transaction** içinde açılır ve aynı transaction içinde sayaçlarıyla güncellenir:
```php
$db->beginTransaction();
$runStmt->execute([...]); // künye açılır (boş sayaçlarla)
$runId = (int) $db->lastInsertId();
foreach ($rows as $raw) { ... } // kişiler bu künyeye bağlanır
$db->prepare('UPDATE import_runs SET inserted = ...')->execute([...]);
$db->commit();
```
Künye ayrı yazılsaydı, kişiler girip künye yazılamadığında **izi olmayan 400 kayıt** oluşurdu — tam olarak bu projenin çözmeye çalıştığı sorun. Atomik modda fren devreye girdiğinde `rollBack()` künyeyi de siler; bu yüzden hemen ardından ayrı bir `aborted` künyesi yazılır: **denenip iptal edilen aktarma da geçmişte görünmelidir.**
---
### Neler Var?