Правильно ли так хранить в таблице локализации статей?

Question

[Кирилл]

Есть некоторая таблица article_tbl, в которой хранятся статьи, допустим, о готовке еды. Все статьи изначально добавляются на русском языке, т.к. все авторы русские.

Но могут возникать случаи, когда ту или иную статью автор переводит на другой язык (английский, немецкий и т.д.).

Скажите, пожалуйста, корректна ли будет структура таблицы article_tbl для хранения таких статей? Вот её вид:


Как вы видите, когда в таблицу добавляется перевод статьи, указывается поле localization (язык) и поле parent_id, указывающее на оригинальную (не переведённую) статью. Это делается для того, чтобы в web-приложении можно было удобно получать статью на нужном языке в зависимости от того, в какой стране просматривается web-сайт. Т.е., в Германии увидят все статьи, которые на немецком, но они смогут посмотреть при желании и на русском.

Таблица, заполненная данными, выглядит примерно так:


Правильно ли хранить локализации статей в таком виде? Или лучше завести промежуточную таблицу? Заранее спасибо!

Answer 1

[Евгений Калибров]

По идее статьи на любом языке должны быть равнозначными, то есть не должно быть parent_id.

Я бы завёл таблицы:

atricles_localization_tbl:
id | localization | title | content | article_id

article_tbl:
id | image | create_date | category_id

Тогда вы сможете в article_tbl записывать общие для любой локализации данные по статье. Но ваш подход тоже имеет право на жизнь.

Comments

[Кирилл]

А если для случая с parent_id тоже добавить общие поля, но заполнять их только у той записи, у которой parent_id == null ? Т.е., поля, к примеру, image, create_date и category_id сделать необязательными.

И вообще, для случая с parent_id есть ли какой-то выигрыш в производительности при выборке? Например, быстрее select и т.д.

Не проигрывает ли в скорости селектов случай со второй таблицей?

[Евгений Калибров]

Кирилл, а зачем вам эти лишние null? Вам в запросе всё равно нужно будет получить общие поля и удобнее сделать это через JOIN, и он не будет проигрывать по скорости запросу с вашей структурой.

[Кирилл]

Евгений Калибров, ладно, сравним :-) А то приходилось как-то встречаться с такой практикой хранения. Вроде компактно и джойны не нужны.

[Евгений Калибров]

Кирилл Вам помог мой ответ? Хорошей благодарностью будет, если вы отметите его решением на данный вопрос.

[Кирилл]

Евгений Калибров, всё же я решил оставить так, как я изначально делал. Но Ваш ответ показался мне интересным, поэтому поставил плюс.

[Евгений Калибров]

Кирилл, да, как я и писал, ваш подход тоже имеет право на жизнь, главное что бы работало без багов.