powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Как правильно хранить биллинговую информацию
21 сообщений из 46, страница 2 из 2
Как правильно хранить биллинговую информацию
    #40036935
Alex_Toms
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
varchar(100) тоже много.

Посмотрел номера контактов на сайте Oracle
У Греции номера 15 символов, скорее всего должно хватить длины 20-25символов.
Greece +30.210.67.89.450 +30 210 678 9215
Hungary +36.1.2241800 3618017722
Israel +972.3.9273677 +44.207.1312.982
Italy +39.06.52436.400 39 028 733 5050
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037007
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Toms
varchar(100) тоже много.

Посмотрел номера контактов на сайте Oracle
У Греции номера 15 символов, скорее всего должно хватить длины 20-25символов.
Greece +30.210.67.89.450 +30 210 678 9215
Лучше смотреть на сайтах, относящихся к телефонии, а не к базам данных :-)

У Греции 12 символов, но да, по стандартам может быть до 15.
Только не забывайте, что в номер могут добавляться дополнительные локальные расширения, т.е. внутренний номер компании может быть частью "полного" номера.

В принципе коммутаторы рассчитаны на 18, так что можно ограничиться varchar(18).
Единственно, непонятно, какой профит, сколько рублей, получит бизнес, если выберет 18 вместо 100 :-)
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037018
Sandist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
спасибо большое, тогда соответственно сделаю varchar(100) - на всякий глянул статью по производительности разных длин при сортировке, кому интересно "https://habr.com/ru/post/489182/"

еще может кто помочь правильно определять префикс (чтобы можно было по нему корректно определить страну , регион и оператора)
может у кого уже есть наработка, не совсем понимаю как в таком разнообразии (куче) различных вариантов определить правильно эти данные
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037019
Alex_Toms
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не помню какой был размер этого поля в таблице, давно не работаю с биллингом.
Номера на сайте привёл для ориентира.
Руководствоваться нужно согласно документации по связи, а не то что разместят на сайтах.
Про дополнительные символы в номерах я уже упоминал, они бывают и их тоже приходилось учитывать.
А 18 вместо 100, это чисто от разработчика. Не делай лишний размер поля если в этом нет необходимости.
Деньги здесь не причём.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037028
Alex_Toms
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как я определял оператора.

Приходили номера например
+79029159999, 89029159999 или 81079029159999.
Отсекал префикс, приводил к одному виду кажется к такому 79029159999.
Исходный номер не трогал, это только в расчётах.
Далее для приводимого примера

Для диапазона 9029150000-9029159999 в систему заносил 7902915.
Далее проверял запросом
select *
from (
select '79029159999' P
) T
where P like '7902915%'

Поле P из таблицы вызовов, а 7902915 из таблицы номерной ёмкости.

Работает достаточно быстро, за раз обрабатывает все записи.
При обработке отсекаем обработанные записи.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037091
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sandist
еще может кто помочь правильно определять префикс (чтобы можно было по нему корректно определить страну , регион и оператора)
может у кого уже есть наработка, не совсем понимаю как в таком разнообразии (куче) различных вариантов определить правильно эти данные
Всё делается лайком по справочнику, как написал Alex_Toms
Единственно добавлю, что справочников должно быть несколько, отдельно для стран, регионов, операторов, т.к. для страны вы можете получить правильные данные почти гарантированно, стран же немного, а вот для остального получится уже не так точно.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037097
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvg
Sandist
еще может кто помочь правильно определять префикс (чтобы можно было по нему корректно определить страну , регион и оператора)
может у кого уже есть наработка, не совсем понимаю как в таком разнообразии (куче) различных вариантов определить правильно эти данные
Всё делается лайком по справочнику, как написал Alex_Toms
Единственно добавлю, что справочников должно быть несколько, отдельно для стран, регионов, операторов, т.к. для страны вы можете получить правильные данные почти гарантированно, стран же немного, а вот для остального получится уже не так точно.
Ещё удобно вместо разных справочников делать перекрывающиеся шаблоны, и выбирать TOP 1 по максимальной длинне найденного шаблона.

Например, для номера 74953631234 будут найдены шаблоны:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
select *, row_number() over(partition by Num.P order by len(Templ.P) desc) as row
from (
    select '74953631234' P
    union all
    select '79161234567' P
) Num
    join (
        select '7%' P, 'Россия' Descr
        union all
        select '7495%' P, 'Москва, оператор фиксированной связи МГТС'
        union all
        select '7495363%' P, 'Москва, оператор сотовой связи MTS'
        union all
        select '7916%' P, 'Москва, оператор сотовой связи MTS'
    ) Templ
        on Num.P like Templ.P
order by Num.P, row
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037104
Alex_Toms
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хватит одного справочника, проверено на практике.
Надеюсь к вечеру немного освобожусь, поищу прежние наработки, вспомню подробнее как делал.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037109
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sandist,

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

Например,
499001
49901
4991
499

Второй способ - написать CLR функцию, в которую загрузите справочники направлений и будете парсить уже каждую строку таблицы, т.е. таблица будет обработана за один проход. Функция внутри себя будет подбирать коды также в порядке убывания длины.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037115
Alex_Toms
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Именно так я и делал.
Сначала обрабатывал с максимальной длиной из справочника, у вас в примере 11.
Далее с длиной 10, 9 и так далее до 1.
Порядок должен быть такой, а не наоборот.
Всего максимум 11 запросов update.
При обработке исключал обработанные записи.
Перед запросом update проверял, есть ли не обработанные записи, если нет, то заканчивал обработку.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037127
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосов
выполнять парсинг номеров по получившемуся справочнику, по одному проходу на каждую длину. Это достаточно быстрый способ, получается не более 11 проходов по таблице.
А чем хуже одним запросом, без "проходов"?
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037128
Alex_Toms
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пока занят, потом отвечу...
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037207
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvg,

Быстрее получалось, не требуется сортировка, например. Но при условии, что памяти достаточно для буферизации необходимой части данных.
Реально не 11 проходов, а меньше.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037230
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосов
Быстрее получалось, не требуется сортировка, например.
Вы же пишите, что
Владислав Колосов
выстроить коды в порядке убывания по длине и выполнять парсинг номеров по получившемуся справочнику, по одному проходу на каждую длину.
Выстроить и есть сортировка, разве нет?
Правда, тут будет только сортировка справочника, а не всего набора.

В общем, интересно было бы сравнить.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037235
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvg
Правда, тут будет только сортировка справочника, а не всего набора.
Кстати, сервер тоже может делать не сортировку, а цикл, а внутри сканы справочника. Если это выгоднее. Притом можно сделать кластерный индекс по длине.
Т.е. по сути можно этот алгоритм "выстроить коды в порядке убывания по длине и выполнять парсинг номеров по получившемуся справочнику, по одному проходу на каждую длину." написать одним запросом:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
create table Template(P varchar(100), Descr varchar(100), L int)
create clustered index idx_Template_L on Template(L desc)
insert Template
select *, len(P)
from (
select '7%' P, 'Россия' Descr
union all
select '7495%' P, 'Москва, оператор фиксированной связи МГТС'
union all
select '7495363%' P, 'Москва, оператор сотовой связи MTS'
union all
select '7916%' P, 'Москва, оператор сотовой связи MTS'
) t

create table Num(P varchar(100))
insert Num
select '74951234567' P
union all
select '74953631234' P
union all
select '79161234567' P

select *
from (
    select * from Num
) Num
    cross apply (
        select top 1 * from Template Templ where Num.P like Templ.P  order by Templ.L desc
    ) Templ
order by Templ.L

select *
from (
    select * from Num
) Num
    cross apply (
        select top 1 * from Template Templ where Num.P like Templ.P  order by Templ.L desc
    ) Templ 
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037245
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvg,

В порядке убывания, верно, но... для курсора или цикла. сортировка справочника выполняется один раз, затем во временную таблицу алгоритм отбирает значение, соответствующие длине строки текущей итерации и ищет LIKE совпадения для update.

В былые времена парсинг кодов направлений ~2млн строк на Pentium3 занимал 2-3 минуты.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037250
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосов
В порядке убывания, верно, но... для курсора или цикла. сортировка справочника выполняется один раз, затем во временную таблицу алгоритм отбирает значение, соответствующие длине строки текущей итерации и ищет LIKE совпадения для update.
Так и в моём запросе точно так же, план же есть.
Сортировка только один раз, при наполнении справочника.
А потом тоже без сортировки "ищет LIKE совпадения", только без "во временную таблицу".
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037273
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvg
Сортировка только один раз, при наполнении справочника.
А потом тоже без сортировки "ищет LIKE совпадения", только без "во временную таблицу".
Подумалось, а если сделать секционирование по длине, не будет ли параллельного поиска в справочнике? :-)
Или, как вариант, сделать 11 справочников, и искать с union all
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037284
Alex_Toms
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvg
Или, как вариант, сделать 11 справочников, и искать с union all
Что из одного справочника 11 запросов с разной длиной и с union all или из 11 справочников с union all те же 11 запросов.

А зачем вообще с union all?
В таблице вызовов сделать числовое поле, ссылку на справочник кодов, default(0).
А далее апдейтил это поле для кодов с максимальной длиной из справочника, у вас в примере 11.
Далее с длиной 10, 9 и так далее до 1.
При каждом проходе записей с 0 в этом поле становилось всё меньше.
При наличии в справочнике всех кодов с 0 их не будет.
Всего максимум 11 запросов update.
При обработке исключал обработанные записи.
Перед запросом update проверял, есть ли не обработанные записи, если нет, то заканчивал обработку.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037298
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvg,

не буду спорить, в те времена cross apply еще не было.
...
Рейтинг: 0 / 0
Как правильно хранить биллинговую информацию
    #40037377
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex_Toms
А зачем вообще с union all?
...
При каждом проходе записей с 0 в этом поле становилось всё меньше.
Что бы одним запросом выполнить все 11 проходов, причём что бы они (проходы) выполнялись параллельно.
...
Рейтинг: 0 / 0
21 сообщений из 46, страница 2 из 2
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Как правильно хранить биллинговую информацию
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]