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

Question

У меня есть база данных, где в нескольких таблицах есть столбец email для хранения адреса электронной почты. Поскольку это для опросов, многие значения будут идентичны, более вероятно, идентичны по именам, адресам и т. Д.

Должен ли я иметь основную таблицу Emails, а затем столбец email_id? Таким образом, я храню строки электронной почты только один раз, а не несколько раз в таблицах. Но если я хочу быть уверен, что я храню только уникальные электронные письма, нет ли какого-то ограничения на длину, по которой индекс будет проверять строку на уникальность, поэтому я мог бы хранить несколько копий длинных адресов электронной почты?

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

Является ли это формой «Единой таблицы истинного поиска»?

Answer 1

Должен ли я иметь основную таблицу электронных писем, а затем столбец email_id?

Это на самом деле не имеет большого значения.

Нет ли ограничения на длину, в которой индекс будет проверять строку на уникальность, поэтому я мог бы хранить несколько копий длинных адресов электронной почты?

Нет. Там нет ограничений. Уникальный означает уникальный, а не «уникальный для некоторого случайного предела».

И я думаю: «Это много струнных соединений!»

Так? Струнные соединения не ужасно медленные. Если вы можете доказать , что эти строковые объединения являются худшим узким местом в вашем приложении, то замена строковых объединений на целочисленные FK может ускорить процесс.

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

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

Answer 2

Если проблема заключается только в том, что «участники имеют адреса электронной почты», то я бы сохранял адрес электронной почты, непосредственно связанный с участником, а не нормализовал его в таблице электронных писем. Это потому, что не все «участники» обязательно будут обмениваться электронными письмами.

• Если (и не спрашивайте меня почему, я не понять конечных пользователей) два члена использовать тот же адрес электронной почты, что и происходит, когда один из них меняется их адрес - но другой не хочет?

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

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

Таблица электронной почты Bounceback подходит в любом случае, поскольку это отдельный тип данных (или тип адреса электронной почты).

Что касается строк и длины индекса, то в наши дни, если СУБД заявляет, что она может индексировать или однозначно индексировать строку длиной до X символов (сколько времени получают адреса электронной почты?), Вы можете рассчитывать на это. Он может работать не слишком быстро, так как он должен обрабатывать X байтов данных на ключ вместо 4 (типичный целочисленный объем памяти), но он будет работать.