| Autor | Zpráva | ||
|---|---|---|---|
| joe Profil |
#1 · Zasláno: 12. 1. 2011, 23:54:28
Zdravím,
měl bych jeden takový spíš obecený dotaz na to, jak efektivně vytvořit filtrování záznamů a jestli to jde udělat lépe (především bych poprosil Kajmana_, který se dle odpovědí vyzná, děkuji :-)) Právě jsem vymyslel podobnou situaci, ke které bych se chtěl dostat (s jinými daty a vlastnostmi, ale dotaz by vypadal celkem podobně): Jsou fotky, na kterých je možné označovat uživatele, ti mohou být z různých zemí a u nich bych rád měl možnost nastavit, jakými jazyky se v nich mluví. Uživatelé mohou mít přátele. Takže vazby 1:N nebo M:N. A teď bych chtěl například dotaz, co by provedl: výběr fotek, kde jsou označení uživatelé, - co jsou ze země, kde se mluví také anglicky - a mají v přátelích nějakého uživatele, co jsou ze země, kde se mluví také česky :-) Jestli správně počítám a nepletu se, tak bych potřeboval 6x JOIN. Ale dostal jsem se do situace, kdy jsem jich potřeboval i více. Počítám s tím, že to nebude příliš efektivní při dost záznamech. Dá se to udělat teda nějak jinak nebo "co s tím", aby to nebylo s přibývajícími uživateli a fotky čím dál tím víc pomalejší? (nejedná se mi o dotaz, ani o tento konkrétní případ, ale tak obecně) A navíc by to byl asi celkem používaný dotaz. Kolik je optimálních JOINů a jestli to má nějaký podstatný vliv na rychlost? Díky za odpověď |
||
| tiso Profil |
#2 · Zasláno: 13. 1. 2011, 00:13:54
Takéto dotazy cez veľa tabuliek sa dajú rozdeliť na niekoľko menších, ktoré sa vykonávajú postupne. Napríklad zoznam krajín, v ktorých sa hovorí česky/anglicky (otázne je či to takto máš dobre navrhnuté) nebude nejaký dlhý, takže vieš získať ich id-čka a použiť ich v konštrukcii
WHERE … IN(…) a ušetríš pár JOIN-ov. Hlavný problém sú tie veľké spojenia medzi fotkami, užívateľmi a ich priateľmi.
|
||
| joe Profil |
#3 · Zasláno: 13. 1. 2011, 00:38:52
tiso:
Díky za dobrý nápad, ale tohle není skutečný model (jak jsem psal), ale jen příklad, špatně se mi vymýšlí něco podobného, co skutečně potřebuji. Teď bych to tu ale nechtěl rozebírat. Pro to, co jsem napsal by to šlo, pro to mé hůže, i když jsi mě přivedl na dobrou myšlenku zlehčit si tak celý postup odzadu a pak v tom hledat až to hlavní co potřebuji - v uvedeném příkladu ve fotkách. Ještě je otázkou, jestli je takové rozložení lepší a efktivnější? Ale asi bude... díky. |
||
| tiso Profil |
#4 · Zasláno: 13. 1. 2011, 00:41:56
joe: všeobecne sa odpovedať nedá, treba skúsiť na reálnom príklade, s rôznym objemom dát.
|
||
| joe Profil |
#5 · Zasláno: 13. 1. 2011, 01:03:38
Je mi to jasný, vyzkouším to, jak to naplním nějakými testovacími daty.
Ale jak jsem teď nad tím přemýšlel, tak to moc využít u mě nejde, představ si vazbu vazební tabulku, na obou stranách je poměrně dost záznamů, dáse říct, že to bude skoro stejně co se týká velikosti. třeba fotky - označení uživatelé na nich Takže to WHERE IN () použít nemůžu, protože bych v tom IN dosadil třeba 1000 IDeček. A teď takové omezení potřebuju někde až na vnořeném místě v dotazu, ne na té hlavní tabulce (fotky) |
||
| tiso Profil |
#6 · Zasláno: 13. 1. 2011, 01:22:02
joe: „Takže to WHERE IN () použít nemůžu…“
To som presne myslel tou poslednou vetou v [#2]. |
||
| TomášK Profil |
#7 · Zasláno: 13. 1. 2011, 01:37:14
joe:
Myslím si, že to o moc efektivněji než přes joiny nepůjde - databáze musí tu práci někdy udělat. JOINy na tabulky s indexy jsou relativně rychlé, problém může být s poddotazy, kde se indexy nedají použít. Pokud je to možné, používat INNER JOIN. Možná pomůže dávat podmínky co nejdříve, ale nemám přehled, co všechno optimalizátor dokáže. Pokud je dotaz i přesto příliš pomalý, lze cachovat. Ať už v databázi (dostatečně velká cache, materialized views) nebo v aplikaci (cachování konkrétního dotazu, cachování částí nebo celých stránek). Případně se inspirovat u těch, kteří to dělají ve velkém. |
||
|
Časová prodleva: 13 let
|
|||
0