Soft delete vs hard delete

Kapcsolódó szolgáltatás Weboldal és webshop

MEGHATÁROZÁS

Soft delete: a sor a táblában marad, csak egy deleted_at timestamp vagy is_deleted flag kerül rá, és minden lekérdezés ezt szűri. Hard delete: a DELETE FROM tényleg törli a sort, és a kapcsolódó audit-trail vagy backup őrzi a múltat. A soft delete kényelmes: visszavonható, undo-zható, könnyen audit-álható. GDPR oldalon viszont csapda lehet. A 17. cikk szerinti törlési kérésre („right to erasure”) a soft-deletelt sor még mindig személyes adatot tartalmaz, és ha a háttér-jobok, az analitika, az ML-feature-store vagy a backup ezt továbbra is olvassa, akkor nem teljesítettük a kérést. Megoldás: két szintű törlés. Felhasználói „delete” jelölje soft delete-nek (30 napos visszavonási ablak), és egy ütemezett job 30 nap után tényleg hard delete-elje a PII-t (vagy névteleníti és a numerikus mezőket meghagyja statisztikára).

KAPCSOLÓDÓ FOGALMAK06

SSR (Server-Side Rendering)→
A HTML-t a szerver rendereli kérésre, minden felhasználónak frissen. Dinamikus tartalomra (dashboard) ideális, de lassabb, mint az SSG.
SSG (Static Site Generation)→
Az oldalak build-időben készülnek el HTML-ként, és egy CDN szolgálja ki őket. Szinte nulla TTFB. A DField saját oldala 111+ oldallal fut így.
ISR (Incremental Static Regeneration)→
SSG + időzített regeneráció: a HTML statikus, de megadott intervallumban újragenerálódik. Blog-cikkekhez ideális · frissesség CDN-sebességgel.
Edge rendering→
A kód a felhasználóhoz legközelebbi CDN-pontban fut (Cloudflare Workers, Vercel Edge). Dinamikus válasz ~10–50 ms TTFB-vel.
RSC (React Server Components)→
React-komponensek, amik kizárólag szerveren futnak, és nem kerülnek át a böngészőbe. Eredménye kevesebb kliens-oldali JS és gyorsabb hydration.
LCP (Largest Contentful Paint)→
A legnagyobb látható elem megjelenésének ideje. Google Core Web Vitals zöld küszöbe 2.5s alatt · mi jellemzően <1s alá lőjük a landing oldalakat.

EMLÍTÉSEK A BLOGON08