Administrace komentářů

S pravidlem: "nech to na db" bych souhlasil, jenže tvoje pravidlo tady tedy především není aplikovatelné: naopak bych spíše řekl, že řešení DELETE/INSERT je to nejjednodušší co je - dva jednoduše napsané dotazy (takže todle je strategie nechám to na databázi), zatímco selektivní smazání/úprava/vložení je na napsání daleko složitější (tak jaké nechej to na db?) a jeho vhodnost vyplývá ze znalosti chování databáze (zdali DELETE + INSERT je nebo není rychlejší než UPDATE).

(Navíc ani to pravidlo vždy neplatí: např. v postgresql jsou některé věci napsané jedním rekurzivním dotazem pomalejší, než totéž opsané PLPGSQL funkcí - např. získání kořene stromu - jestli si to teda pamatuju dobře)

--

Souhlasím, že se optimalizace a hrabání v DB zpravidla nevyplatí dělat, ale nikoli proto, že to databáze většinou udělá rychle: to může a nemusí platit, ale hlavně proto, že nejdražší je čas programátora a databáze to většinou udělá rozumně.

Optimalizace je na místě v okamžiku, kdy přestane stačit rychlost: a v tu chvíli je "nech to na databázi" sice dobrá heuristika, tzn. to, co člověk zkusí první a zpravidla bývá přinejmenším blízko k optimu, ale vyplatí se si otestovat pár řešení a vybrat si - a v tom, které možnosti vyzkoušet člověku často napoví znalost vnitřností DB.

--

Ohledně paralelní aplikace: jde o poměr čtení a zápisů: pokud při každém přihlášení uživatele by se měly všechny atributy přepisovat jen proto, že je třeba uložit login time, tak je to blbina. Pokud uživatele založej a jednou za půl roku mu něco změněj a zbytek provozu je čtení, pak se to vyplatí.

--

Ohledně zamykání bloků, tak to je jen dohad, vnitřnosti innoDB jsem detailně nezkoumal, ale co vím innodb má row-level locking a zamyká samotné řádky, nikoli datové stránky (pravděpodobně teda při úpravě dané stránky ji na danej okamžik zamkne, ale to je krátkodobej zámek, kterej by neměl vadit, pokud se spolu nepere n procesů chtějící měnit tu samou stránku; vaděj zámky přes celou transakci). Spolu s tím dělá intervalové zámky na B+stromem. Když se budou updatovat všechny vlastnosti daného uživatele, tak to prostě zamkne dané user_id - a to při změně uživatele jen dobře. Problém tam bude IMHO nikoli v zamykání nějakých bloků, ale v tom, že výmaz většího počtu záznamů může vyvolat štěpení stránek B+stromu indexů, což se bez dalšího zamykání neobejde a může to zasáhnout okolní uživatele.

--

Ohledně InnoDb a clusterování jiní píšou jinak - clusterovaný index v innodb je podle nich (i mne) redundantní B+strom, takže má v listech data, nejen klíč a odkaz na externí datové stránky. http://www.ovaistariq.net/521/understanding-innodb-clustered-indexes/ Koneckonců, kdyby v clustered indexu byl odkaz na data, proč by se měl jmenovat clustered? A proč by v ostatních indexech nemohl být ten samý odkaz, v Tvém řešení by při vyhledávání pomocí sekundárního indexu byl zbytečný seek na clustered index.

--

Poslední Tvé tvrzení nebylo, že to může být lepší, ale že většina databází zápis neměnící data ignoruje. Což IMHO není pravda. Možná neodkládá starou verzi do logu (to nevím, tak hluboko jsem se v zdrojácích nevrtal), v každém případě musí řešit celou proceduru kolem načtení řádky, spouštění triggerů atd..., což má k ignoranci daleko.