Dotaz: Deduplikace hodnot v relační databázi

[xkucf03]

K deduplikaci (odstranění redundance) nás vedou už normální formy, nicméně nejde jen o dodržování nějakých teoretických pouček, ale i o čistě praktické dopady – menší velikost databáze, rychlejší vyhledávání atd.

Jednu informaci bychom měli mít v databázi uloženou jen jednou a z ostatních míst se na ni odkazovat pomocí cizích klíčů.

Co ale dělat v případě, kdy na vstupu máme data v denormalizované podobě (dost běžný jev)?

Dejme tomu, že do databáze budeme ukládat logy (nemusí to být vůbec logy, je to jen příklad). A máme dokonce to štěstí, že máme zvlášť logovací hlášku a zvlášť její parametry a čas – hláška je např.

Chyba v komponentě XY, při parametrech a = {0}, b = {1}

a k tomu máme dvouprvkové pole parametrů a časové razítko vzniku události.

Hláška je konstantní zatímco parametry a čas se mohou měnit. Hlášek v jedné aplikaci budou třeba desítky nebo stovky, ale počty instancí logovaných událostí budou řádově mnohem vyšší.

Můžeme si tedy v databázi vytvořit číselník hlášek a na něj se odkazovat z tabulky událostí.

Tohle jsem si už vyzkoušel v malém a funguje to dobře – do tabulky „událostí“ (nejde o události, ale princip je stejný) neukládám hlášku jako text, ale v tom INSERTu zavolám funkci, která prohledá číselník, v případě potřeby přidá záznam a vrátí ID – tzn.

INSERT INTO udalost VALUES (:čas, moje_funkce(:hláška), …)

místo

INSERT INTO udalost VALUES (:čas, :hláška, …)

Nedochází k duplikacím, databáze je menší, vyhledávání rychlejší… ale při zápisu je potřeba projet číselník a případně do něj přidat nový záznam.

Na základě čeho byste se rozhodovali, zda zvolit tohle řešení (lepší uložení a čtení, ale horší zápis) nebo zda radši rezignovat na normalizaci a připustit duplicity?

Další možnost je přidávat nové záznamy do nějaké fronty (dočasné tabulky) a asynchronně dohledávat hodnoty v číselníku (resp. je tam přidávat) a přesouvat data do trvalé tabulky. Zápis tak může být rychlý a potřebná práce se udělá, až bude čas – ale zase nepůjde vyhledávat v úplně nejnovějších hodnotách.

Existuje k tomu nějaká abstrakce, aby člověk prostě volal INSERTy a SELECTy a nemusel se o nic víc starat? Třeba nějaká sada triggerů nebo modul do databáze? Nebo je potřeba si takovou věc napsat na míru?

Odpovědi

[Kit]

Podle mne je nejpoužívanější abstrakcí

CALL pridej_udalost(:čas, :hláška, …);

Zkoušel jsem i triggery, také to není špatné.

[xkucf03]

To je více méně formalita, jestli to celé zabalíš do funkce/procedury nebo jestli je funkce jen ten kousek který pracuje s číselníkem a zbytek je standardní INSERT. Ale tak jako tak, tu funkci/proceduru musíš napsat na míru – což tedy v současnosti používám, ale šlo mi o to, zda nevynalézám znovu kolo a neexistuje třeba už něco hotového.

[Filip Jirsák]

Pokud sháníš sadu triggerů nebo modul, je potřeba napsat, pro jakou databázi. Pokud by pro ni náhodou něco takového existovalo – spíš bych ale řekl, že si to musíš napsat sám.

Rozhoduju se hlavně podle množství ukládaných dat – kolik se deduplikací ušetří. Řešil jsem to tak, že tabulka s deduplikovanými daty měla sloupeček hash, který sloužil jako primární klíč. Tím pádem procházení číselníku při zápisu nebylo nijak náročné. V případě zápisu velkých dat jsem zvažoval i variantu nejprve se databáze zeptat, zda daný hash zná, a teprve v případě záporné odpovědi poslat data s hashem. Ušetří se tím zbytečný přenos velkého objemu dat mezi aplikací a databází v případě, že by byl záznam duplicitní.

[jekub]

Použil bych pohled, který odpovídá vstupním datům. K tomu trigger instead of insert, který to rozháže do skutečných tabulek (nebo cokoli jiného).

Při insertu nemusíte vědět jaké máte volat funkce, prostě tam sypete hodnoty. To může být výhodné při použití obecných nástrojů pro import.

Nebo data dodává třetí strana, které se zpřístupní takový pohled pro insert a nemusím se starat o vlastní nahrávání. Přitom skutečná struktura zůstává skryta.

Abych to shrnul - db klientovi stačí umět prostý insert, o nic dalšího se nemusí starat.