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

Question

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

0

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

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

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

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

Тем не менее, я хочу добавить другие языки в свое приложение, что означает, что некоторым именам мест также понадобятся переводы (например, London > Londres > Londre и т.д.). Это не будет OTT, возможно, 6 языков и не более. UTF-8 потребуется.

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

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

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

Tom 08 янв. 2010, в 14:39

Источник

Теги:

mysql

geolocation

utf-8

1 ответ

Ещё вопросы

Pekka 웃 · Accepted Answer · 2010-01-08T10-24-00.000Z

Я не знаком с тем, что 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

?

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

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

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