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

Question

В моем приложении каждый из моих пользователей должен выбрать пригород, с которым нужно связать свой профиль.В таблице users есть поле suburb_id, а в таблице suburbs есть поля id и name.

Наша таблица suburbs содержит большинство пригородов, которые нам понадобятсяОднако иногда пользователям нужно будет вводить пригороды, которых у нас нет в нашей таблице, или которые появлялись после того, как мы заполнили нашу таблицу.

Каков наилучший способ проектирования базы данных для решения этой проблемы.

Я рассмотрел вопрос об изменении поля suburb_id на просто suburb и затем проверял в приложении, является ли оно целым числом или строкой - если бы оно было целым числом, приложение предположило бы, что оно связано с элементомв таблице suburbs, если бы это была строка, она бы приняла иное.Однако, если бы пользователь просто вводил целое число в поле suburb, тогда приложение, очевидно, ошибалось бы и пыталось сопоставить его со значением в таблице.

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

РЕДАКТИРОВАТЬ: Я также хотел бы избежать вставки данных, предоставленных пользователями в таблицу suburbs (даже если помечены) поскольку я не хочу влиять на качество данных о пригороде, которые у нас есть.

Answer 1

Может быть несколько способов справиться с этим, но я думаю, что самый чистый способ - это оставить таблицы suburbs и users такими, как они есть, и добавить пригород к таблице suburbs на случай, если пригород неуже не существуетМожет быть, с флагом, что это в пользовательской сгенерированной записи для последующей очистки.

Я рассмотрел вопрос об изменении поля suburb_id на просто пригород, а затем проверял в приложении, является ли оно целым числом или строкой - еслиэто было целое число, которое приложение предполагало бы, что оно связано с элементом в таблице пригородов, если бы оно было строкой, оно могло бы принять иное значение.

Это может легко привести к проблемам с производительностью.

Answer 2

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

• Позволяет пользователю вставлять строки в таблицу пригородов.
• Не позволяйте пользователю вставлять строки в таблицу пригородов.
• Удалить ссылку на внешний ключ.
• Замените таблицу пригородов таблицами супертипов / подтипов , где супертип будет содержать все пригороды, а таблицы подтипов будут отличать предоставленные пользователем пригороды от проверенных пригородов.