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

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

1
Gonzalo Acosta 25 Фев 2015 в 00:00

4 ответа

Лучший ответ

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

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

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

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

1
HLGEM 24 Фев 2015 в 21:21

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

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

0
MaxZoom 24 Фев 2015 в 21:24

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

0
Kirk Powell 24 Фев 2015 в 21:16

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

Есть веская причина установить новую таблицу, например: id, user_id, phone, type, description

Так что type может быть списком Дом, работа, офис2, начальник, жена, факс, мобильный и т. д.

И description вроде «только рабочее время», «вечер», «круглосуточно, без выходных», «только в экстренных случаях» и т. д.

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

1
Alex 24 Фев 2015 в 21:32