Вопрос: существует ли петлевой способ обработки обновлений, если я храню выбранные значения в таблице сопоставления? Иначе, есть ли правильный аргумент (кроме того, он облегчит вашу жизнь) в поддержку второго подхода хранения городов в виде массива идентификаторов.
Context
У меня есть loopback 3
сервер API с MySQL
источником данных. Для хранения значений множественного выбора я использую таблицу сопоставления. Например, у человека много городов. Итак, есть таблица PersonCity, которая имеет person_id
и city_id
. И у меня есть отношение hasMany, которое выглядит так:
"cities": {
"type": "hasMany",
"model": "PersonCity",
"foreignKey": "person_id",
"options": {
"nestRemoting": true
}
}
В моем приложении пользовательского интерфейса требуется раскрывающийся список со всеми городами, и человек может выбрать несколько городов. Я могу узнать города человека, позвонив в API, например, persons/{id}/cities
, что приводит меня ко всем городам из таблицы PersonCity
, где person_id
- это id
, упомянутый в вызове API.
Ответ, который я получаю, выглядит следующим образом:
[{
id: 14,
person_id: 1,
city_id: 1
},
{
id: 19,
person_id: 1,
city_id: 2
},
{
id: 34,
person_id: 1,
city_id: 3
},{
id: 34,
person_id: 1,
city_id: 4
}]
и затем я могу извлечь все city_id
, чтобы получить выбранные города для значения моего раскрывающегося списка.
Проблема возникает при редактировании. Допустим, я хочу удалить один из выбранных городов и добавить еще два.
Один из подходов состоит в том, чтобы удалить город с помощью delete
API-вызова, подобного этому /persons/1/cities/{id}
, а затем сделать вызовы для новых городов. И код UI должен позаботиться об этом. В этом случае пользовательский интерфейс должен иметь информацию о предыдущих городах, определять, какие из них следует удалить, а какие добавить.
Другой подход, который делает жизнь намного проще, - это забыть таблицу отношений и сопоставления, просто сохранить города в массиве city_id
внутри person
и затем обновить человека новым массивом. Массив - это то, что собирает мой блок выбора, и он выглядит естественным.
Я не эксперт по БД, но, следуя правилам проектирования БД, я получил таблицу сопоставления для хранения этих данных, и жизнь для пользовательского интерфейса очень сложна.