Logovanie histórie zmien do jedného stĺpca, aký formát dát?

Ahojte, chcel by som so pre projekt v nette ukladať históriu zmien tak aby bola prístupná, mala jednotný ucelený pohľad. V akom formáte odporúčate historické dáta do stĺpca v databáze vo formalizovanom tvare ukladať, aby ich bolo možné v prípade potreby spracovať, resp. čo pre nette odporúčate? (JSON, XML, … ?)

Ako momentálne logujem:

• do jednej jedinej tabuľky,
• pri každej akcii: prihlásenie, vytvorenie, úprava, mazanie, odhlásenie, chyba v právach, … sa logujú zmeny pomocou obdobnej funkcie:

public function dblog($username, $source, $action, $data) {
    return $this->connection->table('logs')->insert(array(
                'username' => $username,
                'ip_adress' => $_SERVER['REMOTE_ADDR'],
                'hostname' => gethostname(),
                'source' => $source, //napr. názov tabuľky v ktorej úpravy logujem
                'action' => $action,
                'data' => $data //vo formáte, napr.: "id: '2', TYP: 'PocetDniSklad', Od: '5', Do: '30', Popis: '5 - 30 dní vrátane'"
    ));

• v stĺpci dáta sú dáta v nie veľmi dobrom formalizovanom tvare, ale pre človeka pomerne dobre čitateľné.

Čo by som chcel dosiahnuť?

• tabuľku rozšíriť o stĺpec cudzí kľúč, aby bol v stĺpci source nie len názov tabuľky, ale aj stĺpec id riadka pre ktorý bola akcia uskutočnená,
• aby bolo možné niekde v projekte kliknutím na stĺpec zobraziť históriu pre konkrétny riadok pomocou dohľadania názvu tabuľky a id,
• stĺpec dáta by sa v histórií pre konkrétny riadok spracoval do HTML tabuľky (ktorá by bola nezávislá na počte stĺpcov – každý riadok by sa spracovával zvlášť) – nezávislé na dátovej štruktúre, ale neviem aký formát dát mám zvoliť, aby to bolo pre nette čo najnatívnejšie.

Aké výhody má logovanie do jednej tabuľky a dáta do jedného stĺpca?

• nie je závislosť na dátovej štruktúre logovaných dát,
• ucelený pohľad na celú históriu od prihlásenia, akcií, až po odhlásenie používateľa.

Nevýhody:

• dáta v stĺpci „data“ nie sú formalizované databázou,
• ťažšie spracovanie, a vyhľadávanie v dátach,
• takáto tabuľka môže časom výrazne narastať (potrebná údržba).

Aké sú iné možnosti:

• Logovanie do súboru (ťažké vyhľadávanie, menšia prehľadnosť a prístupnosť).
• Pre každú tabuľku mať kópiu historickej tabuľky s tým, že bude navyše ‚id_h‘: id pôvodného záznamu + dátum akcie. Predpokladajme, že pôvodná tabuľa mala info aj o používateľovi, ktorý akciu vykonal. Jednoduché realizovanie db trigermy (before delete, before update, …) bez potreby úpravy v aplikácií. Nevýhodou je kópia tabuliek pre históriu. Výhodu je rýchlejšie hľadanie, keďže každá tabuľka má vlastnú historickú tabuľku… komplikovaný pohľad na ucelenú históriu od prihlásenie až po odhlásenie používateľa.

Editoval _rasel^ (16. 9. 2016 13:12)