Zjednodusenie query

Mam v db cache ktora ma takuto schemu:

Kód:

CREATE TABLE page_cache (
		cid CHAR(40) NOT NULL,
		etag CHAR(40) NOT NULL,
		data BLOB NOT NULL,
		timestamp BIGINT(20) UNSIGNED NOT NULL,
		PRIMARY KEY (cid)
) COLLATE='utf8_general_ci' ENGINE=InnoDB;

CREATE TABLE page_cache_tags (
		cid CHAR(40) NOT NULL,
		tag VARCHAR(64) NOT NULL,
		INDEX cid (cid),
		INDEX tag (tag)
) COLLATE='utf8_general_ci' ENGINE=InnoDB;

CREATE TABLE tag_invalidation (
		tag VARCHAR(64) NOT NULL,
		PRIMAREY KEY (tag)
) COLLATE='utf8_general_ci' ENGINE=InnoDB;

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

Kód:

DELETE FROM page_cache WHERE cid IN (SELECT cid FROM page_cache_tags WHERE tag IN (SELECT tag FROM tag_invalidation ));

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:

Kód:

DELETE c, t, i FROM page_cache AS c RIGHT JOIN page_cache_tags AS t USING(cid) RIGHT JOIN tag_invalidation AS i USING(tag);

a co foreign key a on delete cascade?

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

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 :).

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:

Kód:

SELECT * FROM tag_invalidation AS i JOIN page_cache_tags AS t USING(tag) JOIN page_cache_tags USING (cid) JOIN page_cache AS c USING(cid);

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.

Původně odeslal node ↪

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...

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é :).

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

Původně odeslal aheadnology ↪

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.