SQL dotazy – počet, trvání (optimalizace?)

Zdravím, řeším teď v CakePHP hudební web a zdá se mi, že mám zbytečně moc dotazů do databáze. Uvedu příklad: http://mojekaraoke.eu/artists/browse/p/page:4 1 SELECT `Artist`.`id`, `Artist`.`name`, `Artist`.`name_sorted`, `Artist`.`url`, `Artist`.`rank` FROM `mojekaraoke_eu`.`artists` AS `Artist` WHERE `Artist`.`id` = 2167 LIMIT 1 1 1 1 2 SELECT `Song`.`id`, `Song`.`artist_id`, `Song`.`name`, `Song`.`url`, `Song`.`url_karaoke`, `Song`.`rank`, `Song`.`preview`, `Artist`.`id`, `Artist`.`name`, `Artist`.`name_sorted`, `Artist`.`url`, `Artist`.`rank` FROM `mojekaraoke_eu`.`songs` AS `Song` LEFT JOIN `mojekaraoke_eu`.`artists` AS `Artist` ON (`Song`.`artist_id` = `Artist`.`id`) WHERE `Song`.`artist_id` = 2167 ORDER BY `Song`.`name` asc LIMIT 20 20 20 16 3 SELECT COUNT(*) AS `count` FROM `mojekaraoke_eu`.`songs` AS `Song` LEFT JOIN `mojekaraoke_eu`.`artists` AS `Artist` ON (`Song`.`artist_id` = `Artist`.`id`) WHERE `Song`.`artist_id` = 2167 1 1 17 4 SELECT `Song`.`id`, `Song`.`artist_id`, `Song`.`name`, `Song`.`url`, `Song`.`url_karaoke`, `Song`.`rank`, `Song`.`preview`, `Artist`.`id`, `Artist`.`name`, `Artist`.`name_sorted`, `Artist`.`url`, `Artist`.`rank` FROM `mojekaraoke_eu`.`songs` AS `Song` LEFT JOIN `mojekaraoke_eu`.`artists` AS `Artist` ON (`Song`.`artist_id` = `Artist`.`id`) WHERE `Song`.`artist_id` = 2167 ORDER BY `Song`.`rank` asc LIMIT 10 1 - načtení informace o interpretovi 2 - načtení interpretových písní (LEFT JOIN info o interpretovi - duplikace přes belongsTo) 3 - počet písní kvůli stránkování 4 - TOP10 interpretových písní (kvůli generování meta description + keywords) (LEFT JOIN info o interpretovi - duplikace přes belongsTo) V případě, že data nejsou v cache, tak ještě: 5 - Celkový TOP10 písní do sidebaru 6 - 10 nejnovějších do sidebaru Pokoušel jsem se udělat první dva dotazy přes JOIN, ale vztah je Artist hasMany Song a CakePHP při hasMany používá ve výchozím stavu raději 2 dotazy po sobě. Jenže při této automatice se mi nedařilo stránkování (načtení Artist hasMany Song - stránkovat Song), tak jsem to udělal jako dva nezávislé dotazy, kdy první je Artist, recursive 0, a druhý je Song (tam asi zruším to belongsTo, zbytečná duplikace dat). Co se doby provádění SQL dotazů týče, tak při prvním načtení stránky je to cca 30 - 80ms, občas se mi ale stalo, že už to bylo i přes 500ms. A já se ptám - není počet SQL dotazů, které vykonávám velký? Příp. není doba jejich generování příliš dlouhá? Je to moje první větší aplikace (7k Artists, 32k Songs, 108k Files), takže vůbec nevím. A ještě jedna otázka, mám pro každou tabulku ještě tabulku dodatečných informací (artists_metas, songs_metas, files_metas), vztah je 1:1. Jenže mi ani u jedné tabulky nesouhlasí počet (artists: 7010, artists_metas: 7009, atd.). Jaký SQL příkaz mám použít pro vypsání všech ID, které jsou v tabulce artists a zároveň nejsou v tabulce artists_metas? Děkuji předem. Sloupce jsou: artists.id, artists_metas.artist_id.

Dobry den. SQL dotaz jako takovy neni az tak moc velky, ale samozrejme je lepsi jej napsat do jednoho pres join a udelat mu indexy na sloupce v kterych se vyhledava filtruje nejcasteji. A pokud by se jednalo o obrovsky projekt, nejlepsim resenim je pouziti noSQL , nebo prestavet MySQL strukturu na noSQL strukturu ;). Ale u dotazu je hlavne dulezite aby nebyl psan takto: select * ..... :) ja tento dotaz nazivam zabijak MySQL :) :) ..

Jaký SQL příkaz mám použít pro vypsání všech ID, které jsou v tabulce artists a zároveň nejsou v tabulce artists_metas? Děkuji předem. Sloupce jsou: artists.id, artists_metas.artist_id.

SELECT artists.id artists_metas.artist_idFROM artistsJOIN artist_metasON artists.id = artist_metas.artist_id WHERE artist_metas.artist_id IS NULLnebo SELECT artists.id artists_metas.artist_idFROM artists,artists_metasWHERE artists.id NOT IN artists_metas.artists_id---------- Příspěvek doplněn 02.09.2012 v 10:08 ----------Osobne ja u velkych projektu to resim, s noSQL databazi. Pripadne s noSQL strukturou na MySQL v kombinaci s memcache. Pokud ti to bylo uzitecny tak jako podekovani bodik nezabije ;)

Dobry den. SQL dotaz jako takovy neni az tak moc velky, ale samozrejme je lepsi jej napsat do jednoho pres join a udelat mu indexy na sloupce v kterych se vyhledava filtruje nejcasteji. A pokud by se jednalo o obrovsky projekt, nejlepsim resenim je pouziti noSQL , nebo prestavet MySQL strukturu na noSQL strukturu ;). Ale u dotazu je hlavne dulezite aby nebyl psan takto: select * ..... :) ja tento dotaz nazivam zabijak MySQL :) :) ..

Jaký SQL příkaz mám použít pro vypsání všech ID, které jsou v tabulce artists a zároveň nejsou v tabulce artists_metas? Děkuji předem. Sloupce jsou: artists.id, artists_metas.artist_id.

SELECT artists.id artists_metas.artist_id FROM artists LEFT JOIN artist_metas ON artists.id = artist_metas.artist_id WHERE artist_metas.artist_id IS NULL OR artist.id IS NOT IN artist_metas.artist_id nebo SELECT artists.id artists_metas.artist_id FROM artists,artists_metas WHERE artists.id NOT IN artists_metas.artists_id Ja osobne bych pro velky projekt pouzil noSQL , pripadne MySQL se noSQL strukturou v kombinaci s memcache ;) Pokud ti to pomohlo plusko jako podekovani neuskodi ;) SQL muzou byt chybne psal jsem to z hlavy takze je bude asi potreba doladit.

Upřímě řečeno pro takto malou databázi bude MySQL bohatě stačit, noSQL databáze se sem moc nehodí. Už vůbec bych principy noSQL databází nezatahoval do relačního světa. MySQL je celkem rychlá, stačí správný návrh a v tomhle rozsahu dat pojede dostatečně rychle.

Tak pro ten 4. bod by se dala udělat spešl tabulka TOP10, kde by bylo těch 10 top songů. Třeba 4x denně bych tuto tabulku přes CRON aktualizoval. tedy spustil ten 4. dotaz a insertnul výsledky do tabulky TOP10. Potom vypsání dat z TOP10 by trvalo chvíli vzhledem k počtu řádků, rozhodně by to o nějaké ms šlo dolu. Nevím, jak to funguje v hudebním světe, ale asi se nemusí při každým načtení stránky ověřovat JAKÝCH 10 SONGŮ JE V TUTO CHVÍLI TOP. Pořadí se snad každou hodinu nemění.

@Jiří Šubr: To je pravda. Ten 4. dotaz je v cachovaném widgetu, takže se ani neprovádí při každém načtení, každopádně díky za tip :)