Ako nemaš neke spoljne ključeve ka drugim tabelama ili druga ograničenja koja nisi ovde naveo, onda definitivno 2, u transakciji.

Oba pristupa koja si naveo se koriste, na tebi je da proceniš na osnovu toga kakva ti je baza koji će ti više odgovarati.

Ne znam da li je dozvoljeno postavljanje linkova do drugih sajtova
http://stackoverflow.com/quest...lways-faster-than-deleteinsert

Ja ne podrzavam delete, bar ne bez zurnal tablele.
Napravi jos jednu kolonu STATUS kojoj mozes vrednost da menjas u zavisnosti od potrebe (VALID/INVALID).

Potpuno se slažem sa onim što je napisao Dr.sima - ne samo da je DELETE nad takvim podacima upitan, čak se treba uzdržavati i sa UPDATE komandom.

U tvom primeru, ako je u pitanju faktura sa stavkama, pitanje je šta se JOŠ desilo osim što je upisan slog (slogovi) u jednoj ili dve tabele. Recimo, odštampana je fakutura koja je završila u nekom DMS-u. Poslata je faktura kupcu. Promenjeno je stanje u skladištu. Urađeno je knjiženje po fakturi itd.

Bez obzira da li se sve gornje zaista i desilo, pitanje je za šta ti trebaju podaci o kojima je reč, pa prema tome treba doneti i odluku.

Jedan pristup, na primer ako podatak treba da završi u nekom DWH sistemu je da se doda polje GENERATION ili VERSION. Ovo je, po meni, bolje rešenje nego imati statusno polje valid/invalid. Na ovakav način imaš istoriju promena, pa možeš iz istorije da rekonstruišeš željeno krajnje stanje. U DWH se takvi podaci NIKADA ne brišu, ali ako je tebi potrebno da imaš takve podatke u transakcionoj bazi, na ovaj način možeš da uradiš čišćenje podataka i da u transakcionoj bazi ostaviš samo poslednju generaciju ili verziju podataka.

Drugi pristup je da u JSON poruku dodaš neke meta podatke. Tipa, ako je dodatata stavka, staviti neki status new=true. Ako je stavka obrisana dodati deleted=true, ako je promenjena, staviti old i new vrednosti za svako polje i oznaku da je stavka apdejtovana.