Zjednodusenie query

2. 7. 2020 17:42:16

Mam v db cache ktora ma takuto schemu:

ked sa zmeni nejaky objekt tak sa invaliduju jeho cache tagy vytvorneim zaznamu v tag_invalidation tabulke. na pozadi bezi periodicka uloha ktora vytiahne tieto invalidovane tagy, podla nich si vytiahne cache id z page_cache_tags a nasledne zmaze data z page_cache podla tychto cache ids.

momentalne to mam robene v niekolkych krokoch - nacita sa napriklad 100 invalidovanych tagov, tie nasledne zmazem, potom sa v slucke nacitaju cache id, taktiez po 100 kusoch, ktore su zhodne s tymito tagmi, a potom zmazem tieto hodnoty z page_cache_tags a page_cache az kym nemam uz ziadne invalidne tagy na spracovanie.

je to jednoduche a funcke riesenie no zbytocne vela dopytov na db kedze toto cele by db mohla vediet spravit sama.

takze hladam riesnie ako to zmaknut jendou embedovanou query :)

toto funguje ale neuprace to po sebe

toto funguje perfektne, az na to ze ak ma cid tag ktory nie je invalidovany tak ostane zaznam v page_cache_tags tabulke lebo nema zhodu na joine:

2. 7. 2020 17:42:16

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456464

TomasX

(4 hodnocení)

2. 7. 2020 18:10:41

a co foreign key a on delete cascade?

2. 7. 2020 18:10:41

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456463

node

(5 hodnocení)

2. 7. 2020 18:13:01

foreign key som v zivote nepouzil a moc ma to ani nelaka :)

2. 7. 2020 18:13:01

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456462

TomasX

(4 hodnocení)

2. 7. 2020 18:17:27

při joinech na innodb ti to výrazně zvedne výkon a můžeš nechat automaticky přes foreign key mazat související záznamy. Není tohle ideální příležitost se naučit něco nového? :)

Např. na pohovorech na programátory je požadavek na dobrou znalost SQL už skoro samozřejmost, také to pečlivě zkouším :).

2. 7. 2020 18:17:27

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456461

node

(5 hodnocení)

2. 7. 2020 18:33:31

pohovor, to je co? :D

je pravda ze s sql som bezne robil kazdy den nez sa frameworky posunuli dalej a pridali kopec abstrakcie. takze sql mi sem tam trosku vrze ale myslim ze to stale zvladam v pohode.

ale proste ja aj tak preferujem jednoduchost a prehladnost. radsej napisem 4 query a kod je cisty, nez vymyslat nejaku jednu vymakanu query ktora zmakne vsetko, ale clovek potom musi riesit co sa tam vlastne deje. preto ani nerobim stored precedures, views ani ziadne podobne moderne ficury. inak povedane som zasadne proti akejkolvek logike v db. db je pre mna len ulozisko a nic viac.

inak tot mi funguje na vypis ale pri mazani nie:

2. 7. 2020 18:33:31

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456460

TomasX

(4 hodnocení)

2. 7. 2020 18:50:18

pohovor nedělám jen na pracovní poměr, ale také, když beru lidi do týmu pro nějaký projekt, spousta věcí se dělá v týmu.

ORM a jiné abstrakce byly jednu dobu zase IN, čisté SQL ale vídám pořád často. Není moc efektivnějších nástrojů jak distribuovaně zpracovat velké množství dat a ještě být schopný dělat testy a formální validace.

Nemůžeš dělat subselect z tabulky, ze které chceš mazat, proto ti to nejde.

Pokud to chceš jednoduše, nejprve si vyber ty id, které chceš mazat (do php, node.js nebo si z nich udělej dočasnou tabulku) a pak maž s where in.

Konstrukci CREATE TABLE tmp_delete AS SELECT ... a DELETE FROM page_cache JOIN tmp_delete ... používáme často na hodně velkých databázích, protože vše zůstane na straně databáze, nemusí se miliony řádků přenášet na klienta a zpět a zároveň to umí db engine optimalizovat a vykonat rychle.

2. 7. 2020 18:50:18

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456459

aheadnology

2. 7. 2020 23:43:13

Napsal node;1589382
foreign key som v zivote nepouzil a moc ma to ani nelaka :)

A já jsem si dodnes bláhově myslel, že spojování tabulek přes foreign key je to zcela nejzákladnější u relačních databází, že ani nic základnějšího nemůže existovat...

2. 7. 2020 23:43:13

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456458

TomasX

(4 hodnocení)

3. 7. 2020 08:26:01

no nejzákladnější, základní a výchozí a první engine MyISAM v MySQL cizí klíče ani neumí. Díky tomu spousta aplikací nebyla nikdy s cizími klíči napsána.

Záleží co děláš za projekty, pokud to jsou one man show, kde to z pohodlnosti nacpeš do plochých tabulek nebo key-value databází (mongo, elastic, redis), k relacím se nikdy nedostaneš. Relační model je způsob dokumentace, předávání informací a komunikace v týmu, je k nezaplacení u dlouhodobých projektů. U velkých projektů či v microservisím světě ho nahrazuje/doplňuje datový katalog. Znám spousty vývojářů, kteří SQL neumí, ale já jsem stará škola a je pro mě důležité :).

3. 7. 2020 08:26:01

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456457

aheadnology

3. 7. 2020 10:30:48

Njn, je vlastně vůbec nějaký název pro takové databáze, jako byla na začátku MySQL, když ne "relační"?

3. 7. 2020 10:30:48

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456456

TomasX

(4 hodnocení)

3. 7. 2020 11:07:08

Napsal aheadnology;1589445
Njn, je vlastně vůbec nějaký název pro takové databáze, jako byla na začátku MySQL, když ne "relační"?

relační model je myšlenkový konstrukt, je to návrhový vzor a nikoliv implementace. Zatímco ACID, FK (foreign keys) jsou implementací/řešením relačního modelu.

Struktorované (hierarchické) databáze se řadí pod souhrnné označení DBMS, to je i MyISAM.

Relační model je často implementovaný jako vrstva nad DBMS v podobě constraints (neznám český termín), takové databáze se pak označují jako RDBMS.

Nikdo ti ale nebrání udělat nad DBMS relační model, cizí klíče si řešit na úrovni aplikace, relační model je jen myšlenkový/návrhový koncept v podobě ER vazeb.

Pěkně to je vysvětleno na anglické wiki, stačí hledat ty zkratky.

3. 7. 2020 11:07:08

https://webtrh.cz/diskuse/zjednodusenie-query/#reply1456455

Pro odpověď se přihlašte.

Přihlásit