Это плохая структура

А потом прилетает требование хранить 11 городов и надо менять структуру бд

Можно сделать 100, и нулами заполнить остальные, типо на будущее

Имеется в виду, что это просто бизнесс правило, к персистансу оно не имеет никакого отношения

Эт шутка была

ты так не шути, а то могут и всерьез воспринять :)

Их проблемы

Кто-нибудь знает способ нормально отправить и нормально распарсить multipart/form-data?

нет. клиент редко будет менять дислокацию. для клиента храниться его дислокация, он смотрит погоду дисклокацию (ГОРОД) сразу показыввать ему крупно. если он сменил. пусть негодяй нажмет на кнопку "показать погоду по моему местонахождению". 😊  тогда если нужно клиент запрашивает апи к другой местности. клиенту показать, диалог "хотите впредь получать погоду по этой местности?" если да, ответит, тогда переключить ему в базе данных. гемора не много, и клиент сам понимает, что он ответственнен, в каком регионе погода ему показывается на данный момент

2 таблицы.
Users
Weather

в таблицы Weather внешний ключ на userID

так нормально?

Что в визер?

id userId city

неправильно таблицу назвал)))))

Да

Так получше

)))

осваиваем нормальные формы на практике

а когда юзер дислокацию меняет за сутки допустим?

не совсем понял

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

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