globalize2 - zapytanie

w jednym z moich projektow mam problem z zapytaniem.
robie tak:

@news = News.paginate(:page => params[:page], :per_page => 20, :conditions => [“news_translations.locale = ?”, “de”], :include => [:news_images, :translations], :conditions => [“category IN (?)”, [“XX”, “YY”]])

generowane sa dwa zapytania.
Z tym pierwszym jest klopot:
SELECT DISTINCT news.id FROM news LEFT OUTER JOIN news_translations ON news_translations.news_id = news.id WHERE (news_translations.locale = ‘de’ and news_translations.finished = 1 and category IN (‘XX’,‘YY’)) ORDER BY news.id DESC LIMIT 0, 20;

distinct powoduje, ze mysql kopiuje dane do pomocniczej tabeli, co przy 2000 rekordow w tabeli news trwa ponad 0,3 sekundy.
usuniecie warunku na locale = “de” i news_translations.finished tez mocno poprawia dzialanie, ale wtedy w wynikach mam tez nieskonczone tlumaczenia, czego chcialbym uniknac.

dodam, ze probowalem z group by i joins, ale efekty niezadowalajace.
indeks zalozony na tabeli news_translations na pare (locale, news_id).

wielkie dzieki za wszystkie sugestie.

Pole ‘category’ jest stringiem?

Fajnie by było uniknąć JOINa (co też ci załatwi DISTINCT), ale to będzie wymagało usunięcia warunków na news_translations. Natomiast jeśli wyciągasz i tak tylko dla 20 newsów, to może będzie szybciej je przeczołgać (poodrzucać/powybierać już konkretne) już po stronie aplikacji?

tak, category jest stringiem.

Twoje rozwiazanie oczywiscie rozwiazuje problem, ale najpierw myslalem nad jakas optymalizacja tego zapytania.
jesli ciezko, trudno, nie jest to sprawa krytyczna :slight_smile:

Skoro już musi być stringiem, to przynajmniej masz na nim index?

No niestety, globalize rozwiązuje problem tłumaczenia kompromisem pomiędzy elastycznością, normalizacją a wydajnością. Jakoś trzeba z tym pracować :wink:

Tak, indeks oczywiscie jest.
Dzieki za pomoc :slight_smile: