Хранение многоязычных геоданных в MySQL

Question

Мое приложение должно использовать геоданные для отображения названий мест. Я хорошо знаком с крупномасштабными сложными геоданными в целом (например, Geonames.org), но не настолько хорошо с возможной реализацией MySQL.

У меня есть собственный набор данных из четырех слоев, включая данные по широте и долготе для каждого: - Континенты (около 10) - Страны (около 200) - Регионы / Штаты (около 100) - Города (около 10К)

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

Пока все хорошо ... на английском!

Однако я хочу добавить другие языки в свое приложение, что означает, что для некоторых названий местоположений также потребуются переводы (например, Лондон> Лондон> Лондон и т. Д.). Это не будет OTT, возможно, 6 языков и не более. Понадобится UTF-8.

Я буду использовать культуры платформы Symfony для обработки переводов интерфейсов, но я не уверен, как мне следует обращаться с именами местоположений, поскольку они на самом деле не относятся к массивным XML-файлам. Решение, которое я имею в виду до сих пор, заключается в добавлении столбца в каждую из таблиц местоположений для «языка», чтобы позволить системе распознавать, на каком языке находится название местоположения.

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

EDIT: После дальнейших раскопок нашел решение этой проблемы с помощью Symfony. Если кто-то найдет этот вопрос, вот ссылка: http://www.symfony -project.org / book / 1_0 / 13-I18n-and-L10n

Answer 1

Я не знаком с тем, что Symfony может предложить в определенных функциях этого отдела. Но для подхода, независимого от фреймворка, как насчет того, чтобы один столбец базы данных в таблице локализаций содержал имя по умолчанию для быстрого поиска - в зависимости от ваших предпочтений, английского названия населенного пункта (Копенгаген) или локального имени (Копенгаген) и Таблица перевода 1: n для остальных, привязанная к каждой местности:

locality ID | language (ISO 639-1) | UTF-8 translation

12345       | fin                  | Kööpenhamina
12345       | fra                  | Copenhague 
12345       | eng                  | Kopenhagen
12345       | dan                  | København

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

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