База данных международных отношений

Question

Я работаю над проектом, который является настроенной и определенной CMS. Во внешнем интерфейсе многие поля будут иметь предварительно заполненные варианты. Однако для этих полей должна быть опция «Другое», которая позволяет вводить текстовую строку пользователем. Область проекта не хочет, чтобы эти новые «другие» значения были добавлены в предварительно заполненные списки (сейчас или в дальнейшем). Это просто исключение. Масштаб проекта настаивает на этой гибкости, которая реализована во всем приложении.

У меня есть таблицы базы данных, которые содержат все эти предварительно заполненные списки. Я называю эти таблицы моими таблицами списков (все начинаются с "списка _")

Мой вопрос касается сохранения выбора, который делает пользователь. Если бы не эта гибкость, я бы сохранил значение в качестве внешнего ключа для соответствующей таблицы списка. Однако для этих полей имеет смысл хранить значение (строку), а не ключ. Недостатками являются индексирование (второстепенное), управление контентом (второстепенное), глобальные обновления, то есть изменение значения в таблице списка не приведет к ретроспективному изменению в системе, если не закодировано (довольно большая проблема).

Я также упомяну, что хранение данных в виде значений, а не ключей делает программирование и функции намного проще (я пишу служебный слой, он сокращает объединения и позволяет функциям быть более общими). ​​

Хранить как значение (строку), а не ключ - это курс, по которому хочет идти команда.

Я совершаю большую ошибку, делая это? Или это довольно часто? Есть ли другие вопросы для рассмотрения?

Альтернатива: Мой альтернативный вариант - добавить строку «Другие» в качестве новой строки в таблицу списков и использовать поле, чтобы сделать ее «скрытой».

Answer 1

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

Тем не менее, «требования» звучат так, как будто это не вариант, что заставляет его «чувствовать», как будто в данных есть несоответствие.Похоже, цель состоит в том, чтобы два хранилища данных двух типов в одном поле: либо предопределенное значение, либо выбранное пользователем значение, и эти два значения имеют разные значения.Не зная больше о системе, трудно сказать наверняка, но это может сделать некоторые типы запросов более трудными для написания (но не невозможно).

Если значение действительно является просто текстовым значением ипредварительно заполненные списки предоставляют простой способ сделать выбор, тогда сохранение значения текста кажется нормальным.Тем не менее, вопрос звучит так, как будто значение присваивается значениям в таблицах поиска.Если это так, то сохранение внешнего ключа может привести к более надежному решению.Но может потребоваться, чтобы значение «Другое» (со связанным с ним значением внешнего ключа) было добавлено в таблицу поиска и другое текстовое поле произвольной формы было добавлено в таблицу для хранения фактического текста, если выбрано «Другое».

Answer 2

Во-первых, концепция таблицы со списком, которую вы описываете, выглядит туманной. Казалось бы, это указывает на то, что спецификация этих объектов не полностью понята или проверена. Вам не нужно отличать «списочные» объекты от не «списочных».

Во-вторых, похоже, что проблема, с которой вы сталкиваетесь, заключается в том, что пользователю предоставляется выбор ввести собственное значение, а не элемент, который может появиться в раскрывающемся списке. В этом сценарии у меня будет специальное значение внешнего ключа, которое представляет «Пользовательский», где я затем покажу текстовое поле для ввода пользователем своего пользовательского значения. Я бы сохранил пользовательское значение в отдельном столбце от значения FK. Всякий раз, когда пользователь выбирал нестандартный выбор, я обнулял пользовательскую запись (в идеале это было бы принудительно выполнено с помощью ограничения Check, но MySQL не соблюдает их, поэтому вам придется использовать триггер). Таким образом, ваша CMS может просто посмотреть, есть ли пользовательское значение, а затем значение из FK. Преимущество наличия как FK, так и столбца для пользовательского текста состоит в том, что вы можете легко изменять структуру родительской таблицы (добавлять атрибуты, добавлять значения, корректировать значения и т. Д.), Не влияя на дочернюю таблицу.