Tiger, не слушай никого.
Самое лучшее решение, запаковывать в бинари(5), по 4 бита на цифру, если напрячься - немного сложнее преобразование, то 3.5 бита на цифру, т.е. 35 бит на 10 цифр, но 4 байта не выйдет по-любому - не влезет туда 10 цифр . Емко, не надо держать внешний ключ. Т.к. Здесь нафиг ключ не нужен, если кроме телефона нет никаких свойств, сами данные и есть ключ, если нужно индекс построил - вот и ключ. Если профиль таблицы - быть свалкой, она должна быть такой. Для нее запросы типа третья цифра "5" - не профиль...

Можно расширить идею, раз надо держать пару, тогда и пакуйте их парой. Тогда можно запаковать два номера по 10 цифр в 67 бит - 9 байт, т.е. по 4.5 на номер. Во как! Но такое использовать можно только в одну сторону, сами понимаете. Если возникнет необходимость в выборках по номерам, то либо через геморрой, либо через добавление распакованных полей, с переливкой из запакованных.

А 80Гб - тоже объем не стоит им пренебрегать, и не важен размер базы, даже если 1Тб.
А оптимизация должна быть с самого начала проектирования, а не вдогонку, когда база подошла к 100Гб.

Вопрос к тем кто за FK:
А вы не пробовали делать справочник цен например(Код цены, Цена)? А из товаров, условно говоря, делать ссылку на справочник цен по коду цены. Очень здорово получается. Только это нафиг не нужно никому. Так и в данном случае, справочник есть смысл вводить если есть дополнительные аттрибуты, а в данном применении никаких аттрибутов нет. Есть только номер и больше ничего не нужно. Так нафига плодить избыточность? Ведь когда FK занимает места относительно столько же сколько и сами данные на которые он ссылается, то смысл в нем сводится к нулю. Или если бы система была ориентрована на анализ данных, то структура должна выглядеть по другому, но анализ - не в этой базе, и не с этой таблицей.

c127Хватает, в случае со справочником это как раз 4 байа
Объясните как! Есть номерная емкость 10^10 (10 цифр по 10 в каждой), в пересчете в двоичную систему для кодирования стольких комбинаций необходимо минимум 34 бита(2^33=8,589,934,592<10,000,000,000<2^34=17,179,869,184). Пренебрегать емкостью(мол, всех комбинаций цифр никогда не будет) разработчик не имеет права. А если вдруг будет?

Правильно, безграмотное решение. Так и в этом случае, тоже самое. Поскольку
ФК будет явно больше по объему 4 байт(если есть сомнения читай выше), то
можно номер и принять за ПК и ФК:
Номера(номер binary(5),...)
Звонки(номер источник binary(5), номер получатель binary(5), ...)
Делаем два ФК на "Номера".
Вот и все. Ну необычно выглядит номер, ну и что? Никто не заставляет нас
хранить данные также как мы их видим. Отображение - это задача приложения, а
не БД и не СУБД. А хранить данные в разреженном состоянии совершенно нет необходимости.

Объясните зачем делать лишнее соответствие типа
Номера(код номера bigint, номер char(10),...)
Звонки(код номера источника bigint, код номера получателя bigint, ...)
???????
Ведь это тоже самое что и справочник цен!!!!

guest_20040621Принципиальная разница. Вы ее действительно не видите?
Вижу принципиальное совпадение. Вы сказали, что цену надо иметь в третей таблице. Так вот в рассматриваемом варианте таблица звонков и есть "третья". И делать оттуда ссылку на данные, когда размер данных равен размеру ссылки - бред. В этом случае данные и ссылка должны совпасть.

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

Это, как я понял, дано по условию задачи и должно быть прописано в ТЗ. Сколько и каких номеров может обслуживать система. Проблема перевода системы с одного диапазона на другой проблема другого уровня.
guest_20040621
2. Не факт, что не понадобится дополнительная информация об абоненте или номере. Даже скорее всего понадобится. Где и как ее прикажете хранить?

Необходима информация - сделайте справочник. Только в качестве ПК в этом справочнике выберете сам номер.
guest_20040621
А зачем восемь байт? Какое количество номерной емкости Вы собираетесь регистрировать? Хинт: у национальных операторов количество абонентов - единицы десятков миллионов.

Сколько в ТЗ написано - столько и должно быть. Написано, что пренебрегаем тем-то и тем-то, то тогда можно и инт заложить. Но опять-таки, никто не мешает сворачивать стринговый номер в инт, и использовать его и в качестве ПК и в качестве ФК. А запаковать и выпаковать 9 цифр в инт вообще не проблема.
guest_20040621
Да наплевать, как он выглядит. Неважно это. Важно отсутствие преобразований.
А вот тут поспорить можно. Что понимается под преобразованиями? К примеру, Вы пишете в базу строку "Альфа", Вы думаете СУБД так и запишет на диск? Нет, пока информация дойдет до физического хранения она перетерпит кучу преобразований, начиная от кодовой страницы(высокоуровневое преобразование) и заканчивая методами записи на магнитный носитель (к примеру манчестерский код и т.п.). Т.е. все эти преобразования идут на лету, Вы их не видите, но это не значит что их нет. Если качественно написать функцию обратимого преобразования, то и не надо заставлять СУБД хранить строковые данные там, где они не должны быть. От избыточности(разреженности данных) надо избавлятся.

Другое дело если СУБД поддерживает упаковку данных на лету, и хранит все запаковано. То тогда физически все будет выглядеть именно так, как я и написал. СУБД запакует эти строковые данные именно в минимально необходимый объем а при запросах будет запаковывать/распаковывать. С одной стороны Вы будете видеть стринги, а на диске это будет занимать места меньше.
Но метод при котором Вы сами закладываете упаковку предметного понятия в тип данных, гораздо лучше, чем встроенное сжатие БД.

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