Administrace komentářů

Klientovi nikdy neposílám velké množství dat. Kdybych měl stručně shrnout co ta aplikace dělá tak:

1. Uživatel nahraje textový soubor
2. Aplikace soubor postupně parsuje a na základě jeho obsahu načítá nějaká transformační pravidla
3. Aplikace transformuje soubor a uloží ho lokálně
4. Aplikace odešle uživateli výsledek operace

Transformační pravidlo T je vlastně objekt. Načítá se z databáze. Každé pravidlo může mít libovolný počet vnořených pravidel. Jednoduše řečeno pravidlo obsahuje pokyny, případně nějaká data, která lze použít při transformaci vstupního souboru. Díky vnořování může být strom pravidel třeba:

T1
├── T8
└── T9
T2
└── T8
T3
└── T8
T4

Když načítám T1, pak aplikace musí načíst i T8 a T9. Když načítám T2, musí načíst T8 atp. Zde je výhodné držet si T8 v cache. Nemůžu si dopředu rozparsovat celý soubor a pak s tím pracovat. Potřebuji šetřit paměť a navíc aplikace nemá jen webové rozhraní a nemusí dopředu znát obsah souboru. Cache už nějak implementovanou mám, zajímalo by mě, zda by to šlo lépe. Takto to funguje:

1. Parser potřebuje T1, pak ho načtu z databáze
2. Parser potřebuje T1, pak ho načtu z databáze
3. Parser potřebuje T1, jenže už ho potřeboval 2x, proto si ho načtu z DB a nacachuji
4. Parser potřebuje T1, jenže už ho potřeboval 2x, provedu dotaz do DB a použiji nacachovaný
5. ...
6. Parser potřebuje Tn, pak ho načtu z databáze
7. Parser potřebuje Tn, pak ho načtu z databáze
8. Parser potřebuje Tn, jenže už ho potřeboval 2x, proto si ho načtu z DB a nacachuji. Pokud už je načtených objektů moc, vyhodím ten nejméně používaný.
9. ...

Neřeším úpravy hodnot databáze další osobou. Data si cachuji jen N sekund. Strom načítám v transakci. Co hlavně řeším je to, že i u bodu 4 provádím dotaz do databáze typu "SELECT t_name, s1, s2, ... FROM t WHERE x = y AND i LIKE ..." a pokud t_name znám, pak si ušetřím konstrukci stromu T1->T8,T9. V tom případě mi ale databáze vrací i nepotřebné sloupce s1, s2, ..., které teď nepotřebuji (strom už mám). Tak je otázkou, zda nenačítat jen t_name a podle potřeby další dotaz na zbylé sloupce a jestli potenciálně vrácená nepotřebná data mají jen zanedbatelný vliv na výkon (výhodu mají určitě v možnosti transakčního zpracování).