Как лучше сохранять в базу данных номера телефонов?

Question

[Йцу Йцуевич]

Форматы номеров могут быть разные, 6, 7, 11 цифр.
Как именно
123-45-67 или 1234567
[phone] --- +7 или 8?

(Во втором случае, я догадываюсь, что можно использовать код страны, из отдельной таблицы)
varchar тяжелее int'а

Answer 1

[Антон]

ИМХО, правильный ответ - как требуется потребителям (другим системам).
Можно сделать несколько полей:
1 - эталонный формат номера varchar2(20 char). Например, 79898112211
2 - преобразованный формат номера. Например, [phone].
При добавлении выдавать пользователю вопрос, хотите стандартно или нестандартно + варианты нестандартных написаний и т.д.
Эталонный формат хранить обязательно. Как ключ. И хранить преобразованный, чтобы не выполнять каждый раз преобразование при обращении.

Comments

[Йцу Йцуевич]

Спасибо!

Последний вопрос:
Вы зарекнулись про ключ, действительно, лучше ли сделать его уникальным и выкинуть ID? Тогда в таблице ВЛАДЕЛЬЦЫ (например), будет связь по самому номеру, тогда будут уходить лишние байты...
Это нормально, можно так сделать? Или всё же оставить ID? Как считаете?

[Антон]

Йцу Йцуевич:Если возможна такая ситуация, что владелец телефона может измениться, то суррогатный ключ (Id) придется оставить =). В противном случае вполне можно использовать ключом номер телефона.

[Йцу Йцуевич]

Точно, спасибо большое!

[ZardoZAntony]

Бред написан про разные форматы в базе. Номер хранят в одном формате в базе - это целое число с кодом страны. Преобразование и форматирование осуществляется как угодно, но исключительно на стороне клиента, чтобы не тратить ресурсы сервера. Ключом его делать нельзя, телефоны нынче меняются как перчатки. ID лучше делать суррогатным и автоинкрементным.

[Йцу Йцуевич]

ZardoZAntony пониже я писал, что в таком случае, пользователь не сможет видеть номер так, как он его записал в поле.
Например, 89-89-11-222-11.
https://toster.ru/answer?answer_id=569417

[Антон]

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

[ZardoZAntony]

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

[ZardoZAntony]

Антон, занимаюсь уже 12 лет разработкой ПО и баз для работы с данными о предприятиях и физ. лицах. Не могу представить задачи, чтобы оправдать избыточность базы в этом случае. Телефон вводит пользователь в любом формате. С него потом убираются все знаки, стартовая 8 заменяется на код страны и он сохраняется в Int64. А вывод форматируется на стороне клиента так как пожелает заказчик интерфейса. Быстро и минимум ресурсов.

[Игорь]

ZardoZAntony,

Телефон вводит пользователь в любом формате. С него потом убираются все знаки, стартовая 8 заменяется на код страны и он сохраняется в Int64.

Вот что-то у меня не получилось сохранить номер 0550 используя целый тип.
Хотя вряд ли есть такие номера.

Answer 2

[Иван Жук]

В базе лучше всего хранить номера в международном формате, в виде 7XXXXXXXXXX (только цифры) в типе Decimal (если используется mysql). При таком подходе вы сможете сделать вывод номеров в любом месте вашего приложения в едином формате, а так же обеспечить корректный поиск и фильтрацию по номерам.

Comments

[Сергей]

Для чего Decimal?

[Иван Жук]

Дмитрий: Decimal - хранит число, как строку, наиболее подходящий формат для хранения номеров телефонов. ИМХО.

[Иван Мельников]

А также минимизировать размер поля:
VARCHAR(11) - 12 Байт,
DECIMAL(11, 0) - 5 Байт.

[Иван Мельников]

Иван Жук, в MySQL DCIMAL хранится как два целых числа – одно для целой части, другое – для дробной.

Answer 3

[Александр]

Можно сохранять номер ввиде числа, а при выборке форматировать его на стороне приложения.

Answer 4

[alex stephen]

varchar с разделением на код города (оператора) и сам номер

Answer 5

[Йцу Йцуевич]

Как насчёт разделителей, лучше их просто удалять?
из 8 (912) 12
будет 891212

Просто тогда мы лишаемся одной вещи.
Может пользователь хочет чтобы его номер видели как:
89-89-11-222-11

Господа, как вы все на это смотрите?

Comments

[DigSil]

Разделители можно будет и в приложении добавить, а вот если будет задача выбрать все телефон у которых 12345 то разделители могут все испортить. Рекомендую хранить телефоны без разделителей и + лучше хранить одним числом .

Answer 6

[ra2003]

Если телефон дается пользователю, то лучше так [phone], если в эксел, то лучше так перед "+7" что нибудь добавлять, например "t" или "_". Выглядит так _+7 [phone] или так t+7 [phone]
Для нормализации удобнее хранить в 10 значном виде 9169182486 (если база ТОЛЬКО по телефонам России и/или Казахстана). По другим странам нужно смотреть какие могут быть варианты и анализировать.
Чуть сложнее бывает убрать двойников из базы (одновременно в ячейке "телефоны" у одной компании: 916918-2486 и 8 [phone]) или "битые" телефоны (когда телефон должен быть 10-7-6 значный в данной стране-городе, а он, например 4-5 значный. С этим лучше бороться программно, например с помощью Питона.

Answer 7

[d-stream]

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

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

То есть для РФ [phone] , [phone], + 7 (876-55) 5-25-25, а эти же номера для немца окажутся 007 900 1000000, 007 876 5229999, 007 876 5552525,

а для усть-урюпинска - могут быть как:

8 900 100-00-00, 8-2 22-99-99 и 5-25-25

хотя в базе - это будет 3+ поля

в принципе хранить имеет смысл как int, а для "хитростей" поиска по частичным маскам - просто держать вычисляемые поля, где номер кастится к [n]varchar