А никто нам и не мешает заюзать compressed_phone_number как FK!!!
И при необходимости сделать справочник номеров, у которого ПК и есть compressed_phone_number.
Я думаю здесь у некоторых людей проблемы с воображением, которые не могут себе представить номер телефона в виде целого числа. А одно из другого конвертируется в раз.

UrriЕсли есть FK:
Ищем значение PK в справочнике телефонов по номеру.
Сначала читаем индекс - это в зависимости от длины таблицы и глубины индексного дерева 3, 4, 5 и более операций чтения.
Потом читаем значение PK. Еще одна операция чтения.
И только потом пишем в таблицу-журнал.

Можно еще упростить. Сначала запаковать (запаковать проще, чем искать в индексе по справочнику) в инт, а потом писать в таблицу-журнал. Сделать ПК запакованный номер, т.е. инт. А распакованый вообще не держать.

Запаковать в unsigned int:
32 бита делим на два куска. Первый два бита - код первой цифры (здесь делаем ущемление прав и кодируем только 4 возможных варианта, закладывается заранее). Второй кусок - 30 бит, им кодируем 9 цифр номера. Да использовать инт тоже нехорошо, а вдруг так получится, что все возможные номера будут в системе, что тогда делать-то? Никакой справочник не спасет.
Если не нравится ущемление, то можно вынести первую цифру в отдельное поле и сделать ключ составным, но это уже изврат.

Можно использовать в качестве хранилища binary(5) - здесь никаких ущемлений диапазонов не будет, и ПК будет простым.

Но поскольку, вероятно определять код страны и т.д. То для улучшения выборок можно сделать это поле составным. binary(3) - для хранения только номера (7 цифр), smallint(2) - для хранения префикса(3 цифр). Более того, в этот smallint можно еще засунуть кол-во впередиидущих нулей: 10 бит - префикс, 2 бит - кол-во нулей, 4 бит - резерв....


А можно забить на это делать и сделать стринг(10)+ПК инт(4). К этому вырастет нагрузка на справочник, т.к. постоянно будет дергаться для того, чтобы выяснить, а какой же ID у такого-то номера... А дергать справочник(чтение памяти, индекса, диска) - это гораздо хуже, чем произвести чистый бинарный расчет(проц и всё).

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