Сабж...
Вопрос такой, в телефонии взаимодействующие операторы работают по так называемым "договорам присоединения", в которых обязуются оплачивать друг другу услуги по пропуску трафика.
Интересно как релизован подсчет услуг по пропуску трафика в известных вам биллинговых системах.

Хм,а где бы взять схему данных/схему работы какой-нибудь старенькой, уже неиспользуемой, никому не нужной interconnect billing system ???

Да это хорошая идея.
Но предложеный Вами способ имеет существенный недостаток. Как показал практический опыт, при использовании запросов и постоянной реконфигурации телефонной сети, часть данных оказывается неучтенной в фильтрах запроса. Например, если оператор А, поключеный к моей сети, получит в свое распоряжение дополнительную номерную емкость, и информация об этом изменении не успеет дойти до меня(а так и происходит), то запрос не только не включит трафик с этой номерной емкости в итоговый счет, но и не позволит определить что такой трафик вообще был.
ИМХО, при использовании запросов часть данных всегда окажется отфильтрованой.
Можно конечно взять все тарификационные запросы(у которых есть where statement), объединить их унионом, и все это вычесть из запроса возвращающего все данные, получим те записи которые отфильтрованы тарификационными запросами. Но этот метод неэффективен, и имеет экспоненциальную зависимость [трафик+операторы]->[трабования к ресурсам].

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

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

Для справки мои условия работы: порядка 150 тыс соединений в день; сервер: 2 xeona по 4 ядра; СУБД Oracle 9.1.

Слабо представляю себе как работать в таких условиях. получается что хотя-бы каждые два дня нужно выполнять запросы, анализировать те, для которых "направление не определено", принимать меры. Но ведь при большом количестве трафика запросы будут выполняться нереально долго.

Уточните пожалуйста, результаты работы запросов Вы использовали непосредственно или предварительно сохраняли их в таблицу?

Скрипты выполняли каждый день или в конце месяца?

авторУточните пожалуйста, результаты работы запросов Вы использовали непосредственно или предварительно сохраняли их в таблицу?
Этот вопрос снят, читал невнимательно :(
Но все же эффективность предложеного метода низка.

В нормальных системах биллинг является не расчетной, а аналитической задачей. Выделяются интервалы времени, в которых определяются условия использования усдуг. В этом интервале по весьма простой формуле вычисляется услуга. Затем проверяется изменились ли условия расчета. если не изменились, то просто берется сумма предудущего временного периода. И все... Все просто, если понимаешь...
Не совсем понятно к чему это...
Стоимость в данном случае это дело десятое. И суммы каждый месяц разные будут.
Вопрос не в том как определить стоимость, а в том как отнести тот или иной звонок к той или иной услуге. И сделать эту систему гибкой, чтобы при изменении предметной области(новые префиксы и т.п.) приходилось вносить минимальные изменения в систему, также изменения в предметной области должны распознаваться автоматом,например "неизвестные префиксы" должны отображаться где-то, чтобы была возм-сть их добавить.

Alex_Toms
Идею уловил, значит при помещении данных о звонках в таблицу, считаем что у всех не опеределен префикс и услуга, затем последующие запросы определяют префикс и услугу.

Надо обдумать...

Замечание принял :)

BDD
А каков статус документа?

Этот документ явлется внутренним требованием к АСР какой-либо компании, примером подобного требования, эссенцией опыта по разработке подобных систем...
Вобщем интересует применимость документа на практике, объемы применения

Спасибо, очень полезный документ.
Конечно было-бы опрометчиво пытаться реализовать в одиночку, непрофессионалу то, что описано в этом документе.
Но как информация для размышления очень полезно.