Silinen Veriyi Başka Tabloya Aktarmak

arkadaşlar herhangi bir kaynak bulamadım fikir de yürütemedim açıkçacı

tablom şu şekilde

tablo adı : mesaj
id
ip
adsoyad
mesaj

ben burdaki bir veriyi sildiğim zaman mesaj tablosundan bu veriyi silicek ve aynı zamanda

tablo adı : cop_kutusu
id
ip
adsoyad
mesaj

tablosuna atıcak

bu konu hakkında bilgisi olan varmı acaba.yardımcı olabilirmi PDO olarak.

Silme işleminden önce aynı verileri cop_kutusu tablosuna ekleyin ardından silin.

foreign key with cascade ile birlikte silinmesini yada silinmemesini düzenleyebilirsin.

yada kendin trigger'da yazabilirsin.

<?php
//önce silinmesini istediğiniz satırın değerlerini alıyoruz
$stmt = $pdo->query("select * from where id='$id'"); // $id değerini nasıl çekiyorsan (post ya da get) bi üst satırda belirtmen gerekecek
$data = $stmt->execute();

//burada aldığımız değerleri çöp kutusuna ekleyeceğiz

$add = $pdo->prepare("insert into cop_kutusu values ('{$data->id}','{$data->ip}','{$data->adsoyad}','{$data->mesaj}')");
$adding = $add->execute();

//veriler çop kutusuna eklendi, şimdi mesaj tablosundan silinecek

$pdo->query("delete from mesaj where id='$id'");

php ile bu şekilde yapabilirsiniz. isterseniz @onekey15; arkadaşın dediği gibi trigger da yazabilirsiniz.

Sana daha pratik bir öneride bulunayım.

Mesaj Tablosuna bir kolon daha ekle DURUM olarak Örnek veriyorum mesajı sildin. O mesajının durumunu 1 yap. Çöp kutusu görevini görür.

cevaplar için teşekkürler geç gördüm biraz fakat kendi sorunu hallettim.

ben işlemi ters yaptığım için çalıştıramadım sonra mantık hatası olduğunu fakettim

tabloya ekleyip silmek en mantıklısı..

ilginiz için tekrar teşekkürler.

Bu gibi durumlarda verileri taşımak yerine bir flag ile işaretlemek daha sağlıklı çözümdür. Ama bunun için yazdığınız sistemin genelinde değişiklik yapmanız gerekir. Senaryo genelde şu şekilde kurulur.
- Tablonuzda deleted_at ya da is_deleted gibi bir sütun oluşturulur. (Ben deleted_at tercih ediyorum, tipini de tarih yapıyorum ki ne zaman sildiğimi de göreyim.)
- Silme işlemi sırasında aslında sql DELETE sorgusu değil, UPDATE sorgusu çalıştırılır. Bu sayede tehlikeli bir işlemden de kaçınmış olursunuz. Tablo yapınız rollback yapmayı desteklemiyor ya da siz rollback uyumlu kod yazmıyor olabilirsiniz. Yanlış bir silme işlemi veri kaybına sebebiyet verir.
- Sitede kullandığınız herhangi bir SELECT sorgusuna koşul olarak "deleted_at is null" ya da "is_deleted=0" gibi silinmediğini belirten ekler yapmanız gerekir.

Veri taşıma ve ardından silme işlemlerinde, diğer tablonun crash olması ya da o anlık insert sorgusu ile ilgili bir sorun yaşamanız durumunda, eğer exception handler kullanmıyorsanız, delete sorgusu çalışacaktır ve taşıma olmadan silme işlemi olacaktır. Çok düşük bir ihtimal de olsa, veriler bizim için önemli, hiç bir zaman DELETE kullanmayın.

panel ve üye panelinde kullandığım bir kısım fazla detaylı şekilde yapmayı planlamadım
yaptığım işlem
submit edilen post ilk önce veriyi başka bir tabloya kayıt ettiriyorum.
kayıt ederken id kontrolü yaptırıyorum ki aynı şeyler yığılmasın.

eğer kayıt başarılı ise sonra submit edilen tobladan veriyi siliyorum.
bu şekilde bir çözüm ürettim kendimce.

bende oracle başta olmak üzere birçok tabloda status değeri kullandık ve doğal olarak mantıklı geldi

oracle devasa boyutda ve anlık transaction olan sistemlerde status değeri ister istemez yavaşlığa sebeb oluyor. Trigger, genel program içinde kod değiştirmek yerine tercih ediliyor. sizde kodları değiştirmek yerine trigger kullanmanız daha mantıklı olabilir

yalnız....
daha sonra silinen data ne idi bakmak istediğinizde sorgu veya execute/commit olunan kodu çok detaylı bilmeniz ve ek olarak delete commit ini veren ip ile user bilgisini/hatta pc id-sini de kaydetmeniz mantıklı olabilir. buda satır bazında 200 karakter lik olan data nın min 300 karakter olması demektir.

ve burda farklı senaryolar ile deleted field çözümleri için farklı bakış açılarını görmek çok hoşuma gitti.

disaster recovery ile uğraşan/uğraşmış- "DBA" - ları selamlıyorum