Kdo někdy vytvářel jakoukliv složitější formu webové aplikace ví, že data se nikdy z databáze natvrdo nemažou, pouze se označí za smazaná nebo expirovaná, není to vůbec důvod aby se data dále posílali na servery NSA ale je to jeden z hlavních bezpečnostích opatření, aby někdo nevyužil bezpečností mezery ve skriptu a nenávratně nevymazal všechna data.
Delete neznamená, že data jsou pryč, jen je záznam v tabulce označen jako neplatný. Např. u souborů DBF je to první bajt záznamu. V tabulce Access se zase vymazání řádku projevilo změnou 5 bajtů, původní data se ale pořád dala dohledat. U větších databází to bude stejné, jde o rychlost - minimalizují se drahé požadavky na zápis. Pokud tedy chci mazat bezpečně, musím nejdřív data přepsat a následně vymazat. Ještě elegantnější způsob (dnes jsem si dohledal) by byl zakódovat řádek tabulky jiným certifikátem, než byl původní. To už je ale databáze s vyšším bezpečnostním standardem :-)
Zjevně jste dnešnímu "modernímu" světu vzdálen již poměrně delší dobu, jinak byste si uvědomoval, že projekty typu Facebook nejsou nějaká one man show, kde programátor dělá co se mu zlíbí. Tam dělá to, co dostane zadané od manažera. A manažer se nepochybně rozhodl že se mazat nebude nic, protože potřebuje pořádné datové sklady pro svůj datamining díky kterému bude později moc lépe cílit reklamu.
Zen, neplkej tu svoje kravoviny, maze naprosto kazda databaze, je jen otazka na jaky urovni, ale z pohledu pouzivani tech dat, jakmile poslu do DB delete, tak sou pryc. Samo, kdybych se zacal hrabat v datovych souborech, tak tam jeste nejakou dobu budou (nez je prepise neco dalsiho).
Z duvodu bezpecnosti/auditovani/... se pak v nekterych pripadech zcela planovite nemaze, ale data se jen jako smazana oznaci (a uchovavaji se trebas i veskere dalsi zmeny), ale to vubec neznamena, ze je smazat nelze.
Pokud se posle do db delete, tak zadny where nepomuze ... jak sem rek (a jak si negramotnej zen neumi precist) data jeste nejakou(obecne nedefinovaou) dobu zustanou v souborech ... ale rozhodne nejsou dostupny aplikaci, ktera pouziva tu databazi. U nekterych databazi pak existujou zpusoby jak vynutit okamzity prepis tech dat tak, aby je proste ziskat nebylo mozne vubec (samo, pokud se pominou zalohy).
Samo, nektery aplikace misto detele poslou do DB nejaky update (zcela zjevne to tak dela FB) a zaznamy si jen nejak oznacuji. Ovsem i v takovem pripade ... je jejich "znovuobjeveni se" minimalne zasadni programatorskou/administratorskou chybou. Nadto u firem nakladajicich s osobnimi udaji je neodstraneni takovych udaju na zadost uzivatele dokonce nelegalni a trestne.
Já číst umím, ale ty jsi nějak roztržitý nebo sebestředný. Jinak bys zaznamenal, že jsem neodpovídal na tvůj příspěvek, ale na příspěvek od
Ditys Cidae ... No a pozornému čtenáři je jasné, že máme v podstatně shodný názor...
To, že se po DELETE záznam nesmaže ovšem nemusí být chyba programátora. Například v případě použití triggeru "INSTEAD OF", což je ovšem akce vynucená programátorem, se záznam nemusí smazat. Je správná programovací technika pokud je výsledkem to, že záznam v databázi zůstane přístupný i do budoucna.
A zde se vracíme k původnímu problému a tím je, že chce-li programátor (respektive zadavatel) aby byl záznam smazán, je to možné a to bez možnosti návratu ať už je provedení jakékoliv (Záznam se smaže fyzicky nebo je jen db systémem označen jako smazán a odstraněn až při nejbližší komprimaci db.).. Neznám databázi, ve které by se po smazání záznamu daný záznam nějakou "chybou" daného db systému (tedy nikoliv chybou programátora) znovu objevil.
Nic jako FB jsem sice nikdy nedělal, ale ve všech aplikacích, ve chvíli kdy se řekne "smazat", tak se smaže. Pokud smazání těch dat nezpůsobí nějaké problémy s integritou, tak neexistuje jejich ponechání jinak než v rámci pravidelných záloh, což je také bezpečnostní opatření pro případ, že by někdo někdy objevil nějakou bezpečnostní mezeru.
Opravdu přestávám rozumět dnešnímu "modernímu" světu, kdy programátoři pod záminkou "bezpečnostní opatření" ignorují právo na soukromí a bez souhlasu majitele, neomezeně dlouho, nakládají s jeho osobními daty.
A k dohledání jste použil Access? Pochybuji. Musel jste použít nějakou jinou aplikaci. My se ovšem bavíme o smazání takového rázu, že po DELETE příkaz SELECT bez nějakých podmínek typu WHERE smazano <> 1 zázname nenajde. Pokud bude proveden v DB DELETE, není pak následně možné, aby se daný záznam znovu objevil, což u Facebooku asi neplatí. Facebook zcela jednoznačně záznamy nemaže, ale cíleně označuje jako "smazané". Pokud někdo tvrdí, že je to kvůli relační integritě, pak je to hloupost. Smažu celou osobu z celé databáze a chci-li ponechat nějaká data, musím změnit u těchto dat primární klíč na nějakou virtuální osobu např. "Mgr.Deletovna Smazaná"...
Je jedno jestli o tom rozhodne programátor nebo nějaký manažer, ta podstata zůstává stejná. Neomezené hromadění dat i přes nesouhlas uživatele - ano v případě FB je to v tomto ohledu horší, protože ten o vás shromažďuje data aniž byste byl u něj registrovaný, tedy dal k tomu jakýkoliv souhlas.
Normálně v MS SQL Serveru se pro příkazu DELETE snaže záznam. Pokud danou věc neprovádíte v transakci, pak je záznam smazán. Nemáte-li zapnutý log, tj. máte-li nastaven Recovery model na Simple a nemáte-li zálohu databáze, data jsou nenávratně pryč. Ještě více destruktivní je pak příkaz TRUNCATE, který kompletně promaže celou tabulku a máte-li nějaké pole Autoincrement, pak nastaví toto pole na výchozí prvotní hodnotu. Stejně pak funguje MS Access... Fyzické smazání záznamu se mimo jiné musí provést v případě, kdy je nad tabulkou vytvořen clastrovaný index (obvykle primární klíč), při kterém dojde k přerovnání indexu... Je ovšem zřejmé, že záznamy v tabulce nejsou fyzicky "setřeseny" a vznikají "mezery". Tyto se nechají "defragmentovat" např. MS Access má volbu "komprimovat při zavření".