Поиск по городам с локальной базой (MySQL) стран и городов на разных языках?

Question

[Sergey Pashkevich]

Добрый день!

На сайте появилась необходимость привязывать товары к городам (дабы потом отображать товары в зависимости от страны или города).

Для реализации были рассмотрены три варианта:

1. Хранение всех стран, регионов и городов на поддерживаемых языках в своей базе
   
2. Частичное хранение с динамическим пополнением (хранение в бд + запись новых данных)
   
3. Завязка на сторонние сервисы (geonames) и хранение его идентификатора в своей базе
   

1 вариант - (похожий вопрос) является самым надежным и верным вариантом, но требует контроля и поддержки. Минус: увеличит размер базы (что при бэкапах может повлиять на скорость).
2 вариант - необходимо в код приложения добавлять дополниельную логику.
3 вариант - также необходима дополнительная логика на преобразования идентификаторов в названия и т.д. Если сервис перестанет работать - то и приложение перестанет корректно работать.

1) Если реализовывать первый вариант и хранить все страны и города (~2млн записей) на разных языках, не будут ли запросы педалить при поиске используя like по нескольким столбцам (разные языки), так как пользователь может вводить на разном языке город, страну?
2) Какую структуру бд лучше реализовать (есть такой вариант)? Подойдёт ли она для штатов, графств и т.д.?

Буду очень благодарен за любые советы! Спасибо )

Comments

[sim3x]

Сколько языков требуется?

2М записей - сколько дамп по времени занимает?
Мастер-слейв уже есть?

Структуру БД делают исходя из всех потребностей проекта и запросов к БД
Потому просто по тому что у вас есть какая-то сущность и вам требуется интернационализация - никто вам хорошую схему не нарисует

Ну и фреймворк/ОРМ может требовать своего подхода к схеме

[Sergey Pashkevich]

Так я не прошу готового решения )
Мне интересно 1 вариант не будет ли тормозить, когда будет происходить поиск и например будет поддержка 10 языков.

Answer 1

[Ambrosian]

1 вариант - (похожий вопрос) является самым надежным и верным вариантом, но требует контроля и поддержки.

Вам все равно придется, потому что

На сайте появилась необходимость привязывать товары к городам (дабы потом отображать товары в зависимости от страны или города).

Comments

[Sergey Pashkevich]

Т.е. 1 вариант самый надёжный, но самый ли оптимальный?

[alex-1917]

Siarhei Pashkevich, а чем же он не оптимальный??)) НОВЫЕ города как бы каждый день не появляются пачками...

[Sergey Pashkevich]

alex-1917, я по поводу производительности в бд. Будут ли запросы быстро выполняться?

[alex-1917]

Siarhei Pashkevich, да я вообще без понятия))) что за БД, как организована,какие запросы и т.д. В моем ОТВЕТЕ я дал ссылку, там вообще без БД идет поиск, по файлу, и это на порядок быстрее, ну если бы по ссылке прочитали, то вопросы бы отпали. Там же и интеграцию делают - хоть с вашими товарами, хоть с языковыми версиями...

[Sergey Pashkevich]

alex-1917, тогда это 3 вариант реализации, который не является самым лучшим.
"3 вариант - также необходима дополнительная логика на преобразования идентификаторов в названия и т.д. Если сервис перестанет работать - то и приложение перестанет корректно работать."

[alex-1917]

Siarhei Pashkevich, файл с базой городов всегда размещается на том же хостинге, где и сайт.
ппц, такая лень самому почитать ? цитировать больше не буду. Отсылаю вопрос в баню!

Answer 2

[alex-1917]

sypexgeo.net/ru/features

но вообще проблема высосана из пальца.
Всего в мире 2,7 млн городов, при этом статус города назначается местными органами. Например в Дании куча городов, в которых живут 250 чел.!!!)) Вы будете туда тоже продавать?)))
По сути если и продавать по всему миру (чо-то сомневаюсь что ТС это имел ввиду)))) ), то ориентир на город с 1млн чел. Таких и три сотни не наберется.
В упомянутом выше сервисе 83000 городов!!! sypexgeo.net/ru/stats