Целесообразно ли разделять таблицы в базе при малом количестве языков?

Question

[bezdealnick]

На сайте может быть максимум 3 языка, на начальном этапе их будет всего 2, 3 язык не факт вообще что будет нужен. Для себя я выделил 2 решения этой задачи.

1. В каждой таблице, где нужен перевод на несколько языков, добавить <наименование поля>_<язык>
   
   Данный вариант мне не особо нравится, так как все-таки есть жесткая привязка в самих таблицах и она будет затруднять добавление нового языка, но с другой стороны больше языков и не будет. Это локальный сервис.
   
   
2. Для каждой таблицы, где есть поля с переводами, делать дополнительную таблицу, например post_language, news_language и т.д.
   Этот вариант мне нравится больше, но он заставляет делить практически все таблицы на 2. Допустим, у меня есть регионы и города, которые также должны быть переведенными. В итоге таблицы превращаются вот в такое
   
   Каждый запрос по сути нужно будет писать такой, который делает выборку из языка по-умолчанию, если на выбранный язык этот текст не переведен.
   
   

Насколько целесообразно использовать 2-ой вариант, при статичном количестве языков?

Comments

[Дмитрий]

А почему не использовать gettext и не нужно будет переводы хранить в базе

[bezdealnick]

Дмитрий, потому что новости, описания продуктов будут динамическими. Хранить это всё в файлах точно не вариант. Статический текст, выводимый во вьюхах будет естественно помещен в языковые файлы.

[Дмитрий]

bezdealnick, я думал там статика

[tormozillo]

На сайте может быть максимум 3 языка, на начальном этапе их будет всего 2, 3 язык не факт вообще что будет нужен.

Это предположение можно назвать надежным только в том случае, если вы сами владелец бизнеса. В противном случае надо подстелить соломку

Answer 1

[BorLaze]

Утверждение "у нас есть три варианта, и четвертого быть не может" в 99% случаев разбивается о хотелку заказчика "ну, у нас уже есть три варианта, это ж не проблема - добавить четвертый?" :-)))