Autor Zpráva
Arynev
Profil *
Ahoj,
právě přemýšlím nad mazáním záznamů. Je lepší používat příkaz DELETE, nebo vytvořit sloupec deleted?

Napište prosím vaše pro a proti k metodám.

sloupec deleted
+Zpětná dohledatelnost záznamů
- všechna data zůstávají > slabší výkon (Mazat je po nějaké době je jedna z možností)
- složitější dotazy
- nutnost smazat navázaná data "ručně"

Použití DELETE:
-záznamy se nedají dohledat
+čistá databáze
+smazání navázaných záznamů (InnoDB)
Alphard
Profil
Před mazáním lze kopírovat do záložních tabulek. Jde hlavně o charakter aplikace, jestli má smysl uchovávat smetí kvůli dohledatelnosti.
Arynev
Profil *
Dám tedy příklad články. Má smysl "složitě" používat sloupec deleted?
Petr__
Profil *
Arynev:
Má smysl "složitě" používat sloupec deleted?
Vždyť na tom nic složitého není. Dáte tomu datový typ
TINYINT(1)
a v dotazu
WHERE deleted = 0
(případně 1, podle toho jak se rozhodnete to značit). Na výkon to bude mít zanedbatelný vliv.

Případně trigger (pokud to daný hosting podporuje), který na BEFORE DELETE vloží daný záznam do archivní tabulky.
Arynev
Profil *
Proto ty uvozovky. Je to prostě práce navíc. Jde mi o to že vyvíjím modelovou část svých aplikací a vybírám způsob který bude nejlepší. Zatím se přikláním k variantě se sloupcem deleted. Také přemýšlím že jej přejmenuji na "status" a v případě některých tabulek se mohou používat i jiné hodnoty (waiting etc)

V případě jednoduchých dotazů pár písmen (WHERE deleted = 0) neni problém, ale složitější dotazy to bude znepřehledňovat, pakliže to bude na každé tabulce
Sir Tom
Profil
Arynev:
V podstatě jenom záleží na tom, jestli budeš potřebovat se "smazanými" články ještě nějak manipulovat. Jestli ano, tak tam dej sloupec deleted. Možná později (až za běhu) poznáš, že tento sloupec je na nic, takže ti nebude vadit, že článek rovnou smažeš. Není v tom velký rozdíl...
Petr__
Profil *
Arynev:
Jak často měníte strukturu databáze a příslušné dotazy do ní, že vám tak záleží na jejich přehlednosti? Potřebuji-li složitý dotaz, tak ho použiji. Když ne, tak ne. Databáze žádnou přehlednost dotazu neřeší.
Pokud chcete archivovat smazané příspěvky v totožné tabulce formou přidání sloupce s jejich statusem, tak prostě budete mít v daném dotazu jeden příkaz navíc. Pokud chcete jít cestou samostatné archivační tabulky, tak zase budete mít trochu "složitější" dotaz při případném slučování těch tabulek. Obě řešení jsou legitimní a jak už psal Alphard, záleží na charakteru aplikace a jak máte v plánu dále pracovat s těmi smazanými záznamy. Těžko vám někdo odpoví konkrétně na obecnou otázku.
Arynev
Profil *
Spíš mi de o to, že si vyvíjim nějaký "obecný model" a tak mě zajímají zkušenosti zkušenějších: jaké řešení se využívá častěji? Není problém jednotlivé funkce přepsat, ale abych je nepřepisoval častěji než je potřeba.
okolojdouci
Profil *
Arynev:
že si vyvíjim nějaký "obecný model"

Tak ho udělej obecný: umožni v administraci nastavit pro každou tabulku normální mazání, nebo "mazání" s možností obnovy.
Někde se používá mazání, někde "mazání"=skrytí. Záleží na okolnostech. Co chceš ještě za radu?
joe
Profil
U dat, které chci uchovat používám sloupec status, který může nabývat například hodnot approved, banned, unapproved, deleted a další.

Arynev:
sloupec deleted
+Zpětná dohledatelnost záznamů
- všechna data zůstávají > slabší výkon (Mazat je po nějaké době je jedna z možností)
- složitější dotazy
- nutnost smazat navázaná data "ručně"

Zvýrazněná část je nesmysl. Pokud záznamy zachováváš, tak se vším všudy, tedy i s navázanými daty na ten konkrétní skrytý/smazaný záznam. To by jsi ho rovnou mohl odstranit, protože už bys nemohl akci vrátit zpět, jako byla původně. Pokud se s těmi navázanými daty pracuje, opět tam bude asi zapotřebí sloupec status se stavem deleted.
Tomáš K.
Profil *
joe:
Zvýrazněná část je nesmysl.
Ne až tak velký nesmysl, i když by smazat mělo být asi v uvozovkách. Přesněji by mělo být 'je třeba ručně označit záznamy jako smazané', pointa předpokládám je, že nelze využívat kaskádového mazání.
PostCC
Profil
Na základě několikaletých zkušeností vřele doporučuji nikoli fyzické mazání, nýbrž využití sloupce s informací o platnosti záznamu. Jen je asi logicky uchopitelnější opačné uvažování - nikoli "Deleted", nýbrž boolean "Validity" s výchozí hodnotou 1. Záznamy, které byly vymazány pak obsahují v tomto sloupci hodnotu 0. Úprava dotazů je minimální, přínos (oproti fyzickému odstranění záznamu) nesrovnatelný.
Arynev
Profil *
[#11] Tomáš K. Přesně tak
PostCCDěkuji za názor, nakonec jsem model tímto způsobem začal přepisovat.
Joker
Profil
PostCC:
nikoli "Deleted", nýbrž boolean "Validity" s výchozí hodnotou 1
Lepší je sloupec s významem „stav“ typu ENUM. Ten se v případě potřeby dá rozšířit o další stavy (třeba „Čeká na schválení“ a podobně).

Tomáš K.:
Přesněji by mělo být 'je třeba ručně označit záznamy jako smazané'
Proč? To se může dělat automaticky.

Arynev:
K původní otázce, jak už bylo zmíněno, univerzální odpověď neexistuje, záleží na druhu ukládaných záznamů.
Okolnosti hovořící pro mazání rovnou:
- Malá „důležitost“ těch záznamů, případně možnost je snadno rekonstruovat i jinak
- Při činnosti aplikace těch záznamů průběžně vzniká a zase zaniká poměrně velké množství.
- Záznamy obsahují unikátní sloupce, které by po smazání měly být použitelné pro nové záznamy (například mám unikátní přezdívku uživatele, přičemž po smazání uživatele by měla přezdívka jít znovu zaregistrovat. Toto se sice dá řešit -unikátní bude kombinace stavu a přezdívky-, ale řešení přes stavový sloupec by pak mělo mít nějaké výhody, které toto vyváží)

Okolnosti hovořící pro mazání změnou stavu:
- Ta stará data mohou být v aplikaci užitečná (podstatné je že mohou být, byť je aplikace momentálně nevyužívá)
- Je výhodné mít možnost zrušit operaci smazání (resp. „odmazat“ záznam), například když uživatel omylem (případně i záměrně) smaže záznam který neměl být smazán.
- Mazání záznamů není až tak častá operace

Pak je ještě „hybridní“ řešení, kdy aplikace ke smazání používá stavový sloupec, přičemž někdy později se záznamy nastavené jako smazané vymažou definitivně.
I to může v některých situacích být řešení.
Arynev
Profil *
[#14] Joker Upravil jsem tabulky a přidal jim sloupec DELETED. Teď vytvářím procedury na smazání navázaných záznamů. Vyšlo mi to asi jako nejlepší řešení. Je potřeba ošetřit ty unikátní hodnoty, děkuji za upozornění.
joe
Profil
Arynev:
Výhodnější je právě mít ten sloupec ENUM status, jak píše Joker - můžeš kdykoli přidat další stav.

Upravil jsem tabulky a přidal jim sloupec DELETED
Pokud bys chtěl teď záznamy schvalovat, přidáš další sloupec APPROVED?

Tomáš K.:
Uvažoval jsem skutečné mazání. Takže by mělo být označit jako smazané. Jak to dělat automaticky ale nevím, možná přes trigger by to šlo (?)
Arynev
Profil *
joe:
mám v úmyslu sloupce deleted a status oddělit. Deleted jinde než v MySQL nebudu využívat, naopak status bude využíván hojně.

Uvažoval jsem skutečné mazání. Takže by mělo být označit jako smazané. Jak to dělat automaticky ale nevím, možná přes trigger by to šlo (?)
Právě vytvářím triggery, jen jich tam je trochu moc. Snad to nebude mít výrazný dopad na rychlost
Joker
Profil
Arynev:
mám v úmyslu sloupce deleted a status oddělit
Záleží na tom, zda stav „smazaný“ nahrazuje předchozí stav uživatele, nebo uživatel může mít nějaký stav a současně být smazaný.
V tom prvním případě je toto chyba, v tom druhém je to správně.
Arynev
Profil *
Joker:
Duplicitní záznamy se ukládat nebudou.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0