‘Globalize is slow’ meme must die

Instead of introduction

Some history of ‘Globalize is slow’

Globalize1 kept all the translations in one table and therefore used polymorphic associations (and, I don’t remember exactly, but possibly every single translated field had its own row). Which of course was slow as hell after the number of translated stuff grew considerably.

Additionally the problem of N+1 queries (for each product on page there was a query for getting its translated fields, each one slow already by itself) was hard to circumvent due to mixed philosophy of catch-all (single polymorphic table) and atomicity (each field in separate row).

Globalize done right

Globalize2 — and, by extension, Globalize3 which is basically “2” but rewritten for Rails3 compatibility allowing for cleaner code and API — used a different approach. Every translated model has it’s own “something_translations” table, consisting of columns with translated values (and, of course, locale for which it’s used). Which is not a very surprising design decision, provided both were developed mostly by Sven Fuchs, the author of the blog post linked above.

Now, theoretically the problem of N+1 queries is still here (every single item needs to query for a single row from product_translations), but it’s hell of a lot easier to prevent it now: