Лучший способ реализовать таблицу поиска «многие ко многим» с данными, введенными пользователем

Скажем, я хочу, чтобы пользователи выбрали один или несколько способов связи (электронная почта, телефон, факс и т. д.). И если они выберут другой, то они могут ввести единственный способ связи самостоятельно. Каков наилучший способ сохранить это в базе данных? Я вижу три возможности:

  1. Используйте столбец заданного типа данных, а также один столбец varchar «other_contact» для хранения необязательного введенного пользователем значения.
  2. Используйте многие ко многим и столбец, введенный пользователем. Таким образом, будет таблица user, таблица contact_method и таблица user_contact_method, которая их соединяет. Плюс столбец varchar user.other_contact для хранения необязательного введенного пользователем значения.
  3. Просто используйте многие ко многим. Та же настройка, что и для 2, но пользователи могут добавлять записи в таблицу contact_method. Но это означает, что мне придется добавить столбец для отслеживания «системных» значений (они не могут быть изменены или удалены пользователями, и только они отображаются в раскрывающемся списке). Кроме того, мне придется добавить дополнительную логику, чтобы разрешить изменение введенных пользователем значений.

Любые комментарии к вышеизложенному или есть лучшее решение?


many-to-many lookup-tables
person M P    schedule 27.07.2009    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

users_table 
id INTEGER
name VARCHAR 
etc.

contacts_table
user_id INTEGER -- foreign key on user.id
contact_method ENUM('email', 'phone', 'mail', 'other')
contact_address VARCHAR
etc.
person Beffa    schedule 27.07.2009
comment
Я понимаю, к чему вы клоните, и мне нравится устранять сложность решения «многие ко многим». Единственная проблема заключается в том, что у меня была другая таблица, для которой также нужны контактные методы. Мне пришлось бы создать аналогичную таблицу для каждого, верно? - person M P; 28.07.2009
comment
вы можете создать таблицу для каждого, если вам нужны высокопроизводительные операторы выбора и, следовательно, иностранные ключи. Другим решением было бы переименовать user_id в foreign_id и добавить дополнительную таблицу столбцов. (Второе решение каким-то образом ориентировано на полиморфный объект.) Для записи в таблице контактов пользователей, внешний_ид будет хранить [идентификатор пользователя], а в поле таблицы у вас будет строка users_table. - person Beffa; 29.07.2009