Блог

В настоящее время база данных имеет 2 отдельных языка: английский и французский. Зная тот факт, что я могу добавить больше языков в будущем, какое из этих трех решений было бы более подходящим?

# 1. Создание отдельных page_translation таблиц для каждого языка:

    CREATE TABLE page_translation_en (
     id INT,
     page_id INT,
     translation LONGTEXT
   );

   CREATE TABLE page_translation_fr (
     id INT,
     page_id INT,
     translation LONGTEXT
   );
  
   ...
 

# 2. Добавление translation столбцов в pages таблицу:

    CREATE TABLE pages (
     id INT,
     page_id INT,
     translation_en LONGTEXT,
     translation_fr LONGTEXT,
     ...

   );
 

# 3. Создание page_translations таблицы, содержащей все переводы

 CREATE TABLE page_translations (
  id INT,
  page_id INT,
  language_id INT,
  translation LONGTEXT
);
 

Повлияет ли 1 МЛН страниц и 3 отдельных языка на производительность запросов для решений #2 amp; #3 , в которых все переводы находятся в одной таблице? кроме того, учитывая, что я хотел бы выполнить поиск по содержанию перевода…

Повлияет ли 1 МЛН страниц и 3 отдельных языка на производительность запросов для решений № 2 и № 3, где все переводы находятся в одной таблице?

Предполагая типичную длину страницы, например, новостную статью, 1 МЛН страниц — это не огромное количество. В системе с разумными ресурсами и правильными индексами переход join между таблицами pages и page_translations должен быть быстрым. Разница в производительности между решениями № 2 и № 3 должна быть незначительной для конечного пользователя.

кроме того, учитывая, что я хотел бы выполнить поиск по содержанию перевода…

В этом случае решение № 3 проще запрашивать. Решение № 2 приведет к неудобному where предложению, например. и т.д. where translation_en like .. or where translation_fr like ..

PS: Я бы рекомендовал изучить дизайн проектов CMS с открытым исходным кодом, таких как WordPress. Я не могу говорить по опыту, но я уверен, что это проблема дизайна, над которой они много думали.