SQL-таблица ИЛИ поле

Question

У меня есть концептуальный вопрос.

В моей базе данных есть таблица, в которой хранится информация о людях. Одним из его полей является их номер телефона (8 цифр для моей страны).

Дело в том, что в некоторых случаях у двух или более человек будет одинаковый номер телефона.

Мой вопрос: будет ли лучший выбор хранить номера телефонов на другой таблице, а затем ссылаться на него с помощью внешнего ключа, а не просто хранить их как поле? Если это так, будет ли результат одинаковым для любого размер БД?

Я не знаю, будет ли это иметь значение, но таблица будет содержать не более 600 000 - 800 000 записей, и я думаю, что совпадающие номера телефонов будут составлять около 10% от общего количества записей.

EDIT:

-Каждый запись может иметь до 4 телефонных номеров (две строки и две ячейки)

ОБЕ случаи будут происходить, будет иногда, когда пользователи будут искать все люди, имеющие конкретный номер, и время, когда пользователь захочет узнать, что все номера телефонов у человека есть

Answer 1

Технически для нормализации у вас будет отдельная таблица номеров телефонов, а затем таблица PersonPhonenumber.

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

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

Если вы хотите историю, то я бы пошел с таблицей людей и таблицей истории aPersonPhoneNumber. Он будет иметь personid, номер телефона, дату начала и дату окончания. Поэтому, когда Джон и Мэри разводятся, его номер телефона будет иметь дату окончания, но ее не будет, и вы могли бы ясно видеть, у кого был номер, когда.

Answer 2

Обычно номер телефона - это просто номер, и без человека не имеет значения. Итак, вы храните его в таблице Person.

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

Answer 3

Если у вас есть более 1 номер телефона на человека

Существует хорошая причина, чтобы установить новую таблицу, как: id, user_id, phone, type, description

Так type может быть список дома, работа, Office2, Boss Жена, факс, мобильный и т.д. ...

и description как "рабочее время только", "вечер", "24x7", «Emergency ОНЛ y "и т. д.

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

Answer 4

Если у вас есть два человека с одним и тем же номером телефона, вы столкнулись с проблемой при поиске определенного номера телефона. Поиск определенного номера телефона иногда возвращает более одного результата (10% в соответствии с вашей оценкой). Если вы ищете по номеру телефона И людьми, вы можете потребовать, чтобы все поиски номера телефона включали идентификатор пользователя (имя, фамилия, место и т. Д.). Это зависит от вашей цели.