Нужен эффективный алгоритм

← →
litr_spirta (2003-04-10 13:53) [0]

Здравствуйте, уважаемые Мастера! Надеюсь, что кто-нибудь поможет...
Собственно задача:
Пишу тарификатор для АТС. В одну из таблиц базы кидается номер звонившего абонента, набранный им (абонентом) номер, время соедирения. В другой таблице забиты коды городов и тарифы.
Необходимо реализовать эффективный алгоритм разбора набранных абонентом номеров по кодам городов и обсчет стоимости разговора.
Основной параметр эффективности - скорость разбора/обсчета.
В связи с вышеизложенным - вопросы:
1. Чем осуществлять обсчет - хранимой процедурой на сервере БД или клиентской частью (софтом).
2. Собственно интересует сам алгоритм такого разбора.

Заранее спасибо за советы/ответы/предложения.

← →
Johnmen (2003-04-10 14:01) [1]

1. ХП
2. То есть написать это дело за тебя ? :)

Приведи, как лично тобой было сделано. А мы попробуем подкорректировать и оптимизировать...:)

← →
Geka (2003-04-10 14:57) [2]

А зачем это делать?

← →
Max Zyuzin (2003-04-10 15:14) [3]

>litr_spirta © (10.04.03 13:53)
Гы...написать биллинговую систему... круто... Как работник службы расчетов (просто биллинга), скажу что это очень навороченая система и я бы за нее в одиночку не брался...
А вообще сперва необходимо превести номера исходящих телефонов к единой маске прежде чем их оценивать.
А где оценивать думаю не играет особого рояля...
Алгоритм простой думаю в идее пройтись по всем звонкам и искать в тарифах скоко это стоит.

← →
Fiend (2003-04-10 15:20) [4]

могу продать уже всё готовое с исходниками, или проконсультировать и дать все алгоритмы уже полностью работающей системы расчёта.
Всё сделано под FireBird. Расчёт выполняется самим Сервером. Софт, тока подбрасывает серверу информацию о звонке, снятую с АТС.
Скорость приблизительно 500 звонков секнду

← →
litr_spirta (2003-04-10 15:40) [5]

To Johnmen:

Нет, за меня ессно писать не надо... ;)

Мной было сделано следующее (вкратце и не особо вдаваясь в мелочи):
Таблица T_CODES (коды городов):
CREATE TABLE T_CODES(
N_CODE INTEGER NOT NULL,
CODE CHAR(8), - код города
TARIF NUMERIC(10,4), - тариф за 1 сек.
CONSTRAINT PK_T_CODES PRIMARY KEY (N_CODES));

Таблица T_CDR (записи о разговорах абонентов):
CREATE TABLE T_CDR (
N_CDR INTEGER NOT NULL,
STNO CHAR(6), - номер звонившего абонента
DIALED CHAR(22), - набранный номер
CONN_TIME INTEGER, - вермя соединения в секундах
CALL_DATE DATE, - дата разговора
N_CODE INTEGER, - ссылка на код города
COST NUMERIC(10, 4), - стоимость звонка
CONSTRAINT PK_T_CDR PRIMARY KEY (N_CDR));

Query1: SELECT * FROM T_CODES;
Query2: UPDATE T_CDR SET N_CODE=:N_CODE WHERE DIALED LIKE :CODE;

фрагмент программы:
begin Query1.Open; Query1.First; while not Query1.EOF do begin Query2.ParamByName("N_CODE").AsInteger := Query1.N_CODE.AsInteger; Query2.ParamByName("CODE").AsString := Query1.CODE.AsString + "%"; Query2.ExecSQL; Query1.Next; end; Вызов StoredProc; end;
В хранимой процедуре опять проходил по T_CDR, селектил из T_CODES
тариф в зависимости от значения поля T_CDR(N_CODE),
умножал тариф на время разговора и updatил T_CDR;

Вот собсно и все.
Не нравится по тем причинам, что приходится по нескольку раз перебирать таблицу по записям и LIKE работает достаточно медленно.

To Geka: А Вы как предлагаете сделать?

← →
Fiend (2003-04-10 15:48) [6]

А зачем вам тогда собсно сервер ИБ. делайте в парадоксе.
Зачем тянуть таблицы на клиента, там чего то еще обрабатывать?

Сделайте всё в сервере, работать будет значно быстрее, чем так как вы реализовали

← →
litr_spirta (2003-04-10 16:04) [7]

To Max Zyuzin:
Вообще-то я не пишу биллинговую систему в чистом виде (имеется в виду коробочную коммерческую версию для продажи) ;)
У меня офисная АТС и примерно 2500 абонентов из разных организаций, а распечатки с уже осчитаной стоимостью звонков дает междугородка.
Мне собственно нужно группировать абонентов по отделам и выставлять в каждый отдел свой счет за межгород.
А сам я обсчет стоимости делаю просто для контроля.

To Fiend: Хотелось бы добиться более высокой скорости - сопоставимой, например с программой PhoneKeeper (www.tsoft.ru)
Они заявляют в своей рекламе об обработке до 10000 записей в секунду...

← →
Geka (2003-04-10 16:10) [8]

Из опыта: самому рассчитывать стоимость междугородних звонков не очень благодарное дело, много подводных камней. Бери то что дают и простыми запросами по отделам...

← →
litr_spirta (2003-04-10 16:17) [9]

To Geka:
Это я понимаю - и тот фрагмент, что я привел - далеко не полный (у меня реально расчитываются стоимости в зависимости тарифных зон/праздничных дней/дневных-ночных тарифов и т.д.).
А задача поставлена начальством - так что хош-нихош, а писать что-то надо. Вопрос остается в скорости обработки.

← →
litr_spirta (2003-04-10 16:25) [10]

Есть мысль все что я написал в фрагменте перекинуть на сервер БД в виде хранимых процедур, НО:
1. Придется подключать внешнюю dll для работы со строками (не хотелось бы в силу определенных причин).
2. Сам подход мне не нравится - проходить по таблице кодов городов и LIKEом искать их в конкретных звонках. А ничего другого более-менее шустрого на ум не приходит.
3. > FiendИБ нужен. Компы в сети сидят, а в бухгалтерии клиентская прога, которая счета выписывает (с дискетами мне бегать не улыбается, а парадоксовские таблицы на сеть расшаривать - по моему еще больший гемморой).

← →
Жук (2003-04-10 16:34) [11]

2 Автор
А вам не приходило в голову, что в набранном номере может быть несколько совпадений к кодами городов ?

← →
Fiend (2003-04-10 16:34) [12]

То litr_spirta:
Думаю о сравнении скорости можно говорить если установить у себя такое же оборудование как у них. Тогда можно хотя бы сравнивать.
У меня к приверу это реализовано на Celeron 800 128Мб ОЗУ, винт не скази. Обрабатывает примерно 500 звонков в секунду. сревер ФБ.
можно конечно сделать и быстрее если пересадить на более мощный сервер и оборудование посильнее взять. Да еще повыбрасывать из моего алгоритма кучу дополнительных обработок, т.к. у меня не только тарификация в одном флаконе.

← →
Geka (2003-04-10 16:37) [13]

Вот как раз и т.д. слишком много. Мне сначала такую же задачу ставили, но сейчас это уже никому и не надо... Взвесьте
У меня Оракл, поэтому по ИБ ничего не скажу

← →
Fiend (2003-04-10 16:41) [14]

То litr_spirta:
про парадокс - это был стёб. Жаль шо вы его не поняли. Просто на него намекнул из за некрасивости вашего метода обработки.

То Жук: сами то поняли что сказали? АТС - это какая то там балалайка там всё продумано и никаких совпадений в разных направлениях там не бывает. К тому же систему кодирования направлений, областей, городов и т.д. придумали очень давно

← →
litr_spirta (2003-04-10 16:52) [15]

> Fiend
%) А, я понял!!! ;)))))))))))
Вот я и попросил совета по поводу красивого метода! ;)

← →
Fiend (2003-04-10 17:42) [16]

То litr_spirta:
Красивый метод сам напрашивается:
вся обработка целиком в сервере.
Больше думаю мало вам кто что скажет. Потому как это денег стоит, и неслабых. Кто же будет давать алгоритмы работы коммерческих программ? Абсурд

Нужен эффективный алгоритм Найти похожие ветки