Table of content Preface Example “Food cuisines” in Talabat. Pre-translations ERD. Pre-translations API. Scope Read-side only. Enum-like database tables. ERD Article. Weakness. API design Final API design. Different original/default languages. API design - other options for `lang` input
Sep 11, 2023·edited Sep 11, 2023Liked by Hossam El-Deen
I work for Talabat and I can relate to this problem :)
I’d say the “cuisines” example & even the whole article you mentioned above is based on 3 assumptions. First, the amount of data is small & static. Second, the data is not frequently updated. Third, We need to support so many languages.
Let’s be pragmatic, how many times anyone wanted to build a software that needs to support more than 3-4 languages? I don’t think it’s a big number. Adding to that, what if the data is huge and denormalization is required to reduce number of unnecessary joins.
I haven’t tried the second approach (to have single column with json format of all translations) but I thought of it as the best approach here, for two simple reasons:
1. Doesn’t require db schema change, which is the drawback of the first approach, whenever you have a new language to add, or when you need say 3 fields, you won’t need to add 3*NumberOfLangauges columns.
2. Doesn’t require at least two unnecessary joins just to fetch a translation of just one field. What if I have 5 fields? Shall I do 10 joins in a single query?
The drawback mentioned in the article is not actually a drawback. The most famous relational database engines now support json fields efficiently. If you relying on an old db version, that’s another problem :)
I work for Talabat and I can relate to this problem :)
I’d say the “cuisines” example & even the whole article you mentioned above is based on 3 assumptions. First, the amount of data is small & static. Second, the data is not frequently updated. Third, We need to support so many languages.
Let’s be pragmatic, how many times anyone wanted to build a software that needs to support more than 3-4 languages? I don’t think it’s a big number. Adding to that, what if the data is huge and denormalization is required to reduce number of unnecessary joins.
I haven’t tried the second approach (to have single column with json format of all translations) but I thought of it as the best approach here, for two simple reasons:
1. Doesn’t require db schema change, which is the drawback of the first approach, whenever you have a new language to add, or when you need say 3 fields, you won’t need to add 3*NumberOfLangauges columns.
2. Doesn’t require at least two unnecessary joins just to fetch a translation of just one field. What if I have 5 fields? Shall I do 10 joins in a single query?
The drawback mentioned in the article is not actually a drawback. The most famous relational database engines now support json fields efficiently. If you relying on an old db version, that’s another problem :)
Thank you for this input ❤️
Indeed, data size and traffic were not concerns for this design. That's why one went with what _seemed_ the most maintainable, normalized solution.
Good notes to take into consideration when one faces the same problem again, isA 👍
Btw, I'm a satisfied user of Talabat. Please, pass my thanks, and to the great, nice riders, as well :)