Как разработать многоязычную базу данных

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

Достичь миллионов пользователей с помощью приложения — мечта любого разработчика. Достижение этой цели становится проще, если пользователи со всего мира могут использовать ваше приложение. Поскольку не все пользователи знают английский или ваш целевой язык, вам необходимо разработать приложение многоязычным. Это невозможно без многоязычной базы данных.

Создать многоязычную базу данных, которая может легко масштабироваться на новые языки, не так-то просто. Именно поэтому вам следует полагаться на передовой опыт. Здесь вы увидите, зачем нужна мультиязычная база данных, три отличных варианта дизайна мультиязычной базы данных и как выбрать лучший из них.

Давайте узнаем все, что вам нужно знать о разработке мультиязычной базы данных.

Зачем нужна многоязычная база данных?

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

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

Заметьте, что предоставление пользователям возможности переключаться между несколькими языками является приятной особенностью. Это особенно полезно для полиглотов или людей, не владеющих родным языком. Поэтому, даже если ваш проект небольшой и ориентирован на местный рынок, вам стоит подумать о мультиязычной базе данных. Ведь вы не можете знать заранее, насколько успешным будет ваш проект и какие пользователи будут его использовать. Давайте узнаем, почему выбор правильного дизайна мультиязычной базы данных для ваших нужд имеет решающее значение.

Почему необходимо тщательно разрабатывать мультиязычную базу данных

Изменение базы данных — очень дорогостоящая операция с точки зрения затрат времени и энергии, поскольку она вызывает эффект пульсации. Изменение структуры базы данных предполагает изменение бэкендов, подключенных к ней. Это также может потребовать соответствующей адаптации фронтендов, которые полагаются на эти бэкенды. Как видите, изменение структуры базы данных не является операцией без последствий. По этой причине вы должны спроектировать базу данных, которая легко масштабируется и которую вам не придется часто менять.

Как вы можете себе представить, существует несколько способов проектирования мультиязычной базы данных, и каждое решение имеет свои плюсы и минусы. Учитывая важность структуры базы данных для приложения, вы должны грамотно спроектировать свою мультиязычную базу данных. Именно поэтому не стоит начинать с нуля, а лучше опираться на передовой опыт.

Давайте сейчас рассмотрим некоторые мультиязычные конструкции, основанные на лучших практиках.

3 дизайна мультиязычных баз данных

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

1. Столбцовый подход

При таком подходе каждое поле в многоязычной таблице имеет количество столбцов, равное количеству языков, поддерживаемых базой данных.

В частности, вот как выглядит шаблон имени столбца: columnName_languageCode.

Плюсы

• Простота: его легко реализовать.
• Быстро: не требует JOIN или медленных запросов.
• Легко работать с непереведенными полями: если перевод для поля отсутствует, вы можете просто использовать COALESCE. Например, COALESCE(name_it, name_en) → возвращает name_it, если оно не NULL, иначе значение по умолчанию name_en.

Минусы

• Сложность в обслуживании: добавление нового языка требует обновления всех мультиязычных таблиц в базе данных. Это также означает, что необходимо соответствующим образом изменить отображения ORM.
• Не масштабируется: количество столбцов в таблицах растет вместе с количеством языков, поддерживаемых приложением.
• Сложные условия SELECT: забудьте о SELECT *. Вам необходимо указать каждый столбец в предложении SELECT.

2. Строковый подход

В этом подходе для каждого языка существует одна строка. Ключом для идентификации мультиязычной сущности является следующий составной первичный ключ:

<id, languageCode>

Плюсы

• Простота: его легко реализовать.
• Быстро: для получения переведенного содержимого требуется только условие WHERE на languageCode.

Минусы

• Сложные ключи: использование составного первичного ключа усложняет идентификацию элемента и запросы JOIN.
• Дублирование содержимого: чтобы упростить ситуацию, непереведенные столбцы обычно хранят то же содержимое, что и столбцы языковой строки по умолчанию. Это означает, что в многоязычных таблицах будет много дублирующегося содержимого.

3. Подход с использованием таблиц перевода

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

Плюсы

• Масштабируемость: добавление нового языка не требует изменений в структуре базы данных.
• Поддержка исторических данных: вы можете использовать таблицу переводов для отслеживания истории переводов для каждого поля сущности.
• Централизованность: все переводы для сущности хранятся в одном месте.

Минусы

• Сложные запросы: запросы становятся более сложными, поскольку информация, связанная с многоязычной сущностью, распределена по двум таблицам.
• Медленные запросы: для получения всей информации, связанной с сущностью, требуется столько же JOIN, сколько столбцов. Учитывая нагрузку, которую JOIN оказывают на производительность, это может легко стать проблемой.
• Дублирование таблиц: это увеличивает размер вашей базы данных с точки зрения таблиц. Кроме того, вам нужно две таблицы для определения каждой мультиязычной сущности.

Какой дизайн мультиязычной базы данных лучше всего подходит для вас?

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

Столбцовый подход особенно полезен при работе с большими данными, особенно с точки зрения наличия базы данных с таблицами, содержащими несколько миллионов строк, когда вы просто не можете позволить себе JOIN запросы или дублирование содержимого. Хотя это не самое масштабируемое решение, подход с использованием столбцов является единственной жизнеспособной конструкцией при работе с большими данными.

С другой стороны, подход «строка за строкой» полезен, когда филиалы вашей компании, работающие на местном рынке, имеют свободу действий. В этом случае дублирование контента может даже стать преимуществом.

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

Заключение

Разработка базы данных, способной хранить многоязычные данные, необходима для того, чтобы помочь вашему бизнесу выйти на международный уровень. Кроме того, это позволит не носителям языка использовать ваше приложение. Изменение базы данных — это сложная и трудоемкая операция, которая может оказать негативное влияние на архитектуру приложения. Именно поэтому с самого начала следует проектировать базу данных как мультиязычную. Здесь мы рассмотрели три различных подхода к проектированию многоязычной базы данных, изучили их плюсы и минусы и подробно остановились на том, какой из них лучше всего подходит для вас.