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

Дано:
Есть некая биллинговая информация хранящаяся в формате xls и xlsx, которую я планирую заливать в скуль. На тек момент информации около 2-3 миллиарда записей, информация будет статична, менять ее никто не будет, но будут запросы к ней, аналитика и отчеты. Вообще по хорошему это идеальный (как по книжке) вариант DWH о котором я мало что знаю. Но тем не менее поделюсь своим делитатнтским мнением и надеюсь на ваши уточнения и помощь.
Из полей:
Дата+время на начало коммуникации
Дата+время на конец коммуникации
Длительность соеднинения
Номер телефона абонента
Номер телефона собеседника
Базовая станция (LAC, CID) абонента на начало коммуникации
Базовая станция (LAC, CID) абонента на конец коммуникации
Базовая станция (LAC, CID) собеседника на начало коммуникации
Базовая станция (LAC, CID) собеседника на конец коммуникации
Хранение:
Все данные разбиты по папкам (название папки - это ориентир для разделения) и хранятся в формате EXCEL
Особенности:
Данные заливаются в одно и то же время за раз около 1 миллиона соединений (на это время система недоступна)
Номер телефона может быть текстовым (internet, gritmer, xbtr...) и может превышать 11 символов (например звонок из других стран)
В основном поиск будет осуществляться по лаку и сиду, по местоположению (долгота и широта), номеру телефона

Что думаю Делать:
1. Справочник Папок (id, название папки)
2. Справочник Базовых станций (id, LAC, CID, широта, долгота, азимут, мощность, ожидаемая дальность)
3. Справочник номеров телефонов (id, номер телефона)
4. Основная таблица (id папки, ДатаВремяНачала, ДатаВремяКонца, длительность(в секундах smallint), id номера абонента, id номера собеседника, id базовых станций)

Основной вопрос заключается в этих самых справочниках, и в типах данных хранения. Заливаем данные 1 раз а читаем часто, стоит ли выносить хранение данные в отдельные справочники (особенно номер телефона) или же лучше денормализовать и залить все данные в одну таблицу сразу? Много ли потеряю при джоинах (если правильно foreign key настроить ключи и индексы)?

Megabyte,

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

Megabyte,
да, идею я понял
не понял только почему эти же 3 или более символов нельзя добавить к номеру телефона и искать сразу по одному полю, а не по двум в запросах? в чем ускорение или экономия?

Alex_Toms,

спасибо всем за помощь
я тоже пришел к тому что буду хранить номер телефона в том формате в котором он приходит
+ в поле буду хранить код
+ регион
+ страна

то есть у меня всегда будет заполнен номер телефона а вот код, регион и стана могут не распознаваться
отсюда есть вопрос как думаете сколько символов достаточно для номера телефона? для 2-3 миллиардов в моем случае даже 1 символ будет много играть (пространство имею ввиду). Я прочитал что 18 символов должно хватить, но вот мне что-то подсказывает, что это избыточно

Ниже аналогичный вопрос на stackoverrun
https://stackoverrun.com/ru/q/117000
авторAssuming you don't store things like the '+', '()', '-', spaces and what-have-yous (and why would you, they are presentational concerns which would vary based on local customs and the network distributions anyways), the ITU-T recommendation E.164 for the international telephone network (which most national networks are connected via) specifies that the entire number (including country code, but not including prefixes such as the international calling prefix necessary for dialling out, which varies from country to country, nor including suffixes, such as PBX extension numbers) be at most 15 characters.

Call prefixes depend on the caller, not the callee, and thus shouldn't (in many circumstances) be stored with a phone number. If the database stores data for a personal address book (in which case storing the international call prefix makes sense), the longest international prefixes you'd have to deal with (according to Wikipedia) are currently 5 digits, in Finland.

As for suffixes, some PBXs support up to 11 digit extensions (again, according to Wikipedia). Since PBX extension numbers are part of a different dialing plan (PBXs are separate from phone companies' exchanges), extension numbers need to be distinguishable from phone numbers, either with a separator character or by storing them in a different column.


Я вот думаю, может достаточно 15 символов, а если будут префиксы типа 0880 или подобное, то они поместятся для Российских номеров, а если и нет, то это в районе погрешности, думаю таких будет оч оч мало.

Как думаете 15 достаточно с учетом того, что я убираю все символы '+', '()', '-' и пробелы?

Alex_Toms,

разве если указать поле varchar (100) место резервироваться сразу под 100 символов не будет?

спасибо большое, тогда соответственно сделаю varchar(100) - на всякий глянул статью по производительности разных длин при сортировке, кому интересно "https://habr.com/ru/post/489182/"

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