Примитивная схема:
читатель логов -> агрегатор -> загружатель в базу -> тарификатор

Более сложная включает в себя разные способы сбора сырого трафика (CDR, Radius, etc.), отсутствие агрегатора и быструю загрузку прямо в мозг БД (на Oracle и им подобных, поддерживающих direct load) и много всякой другой ерундистики.

Тарификация может выполняться как при загрузке трафика, так и постфактум (раз в N-ое количество минут).

А насчет триггера - уже было сказано, что идея крайне плохая.

А вообще - тема интересная.
С удовольствием написал бы свой маленький биллинг (применяя знания полученные на работе с большими системами).
Куда его только потом девать - бесплатно раздавать что-ли?

postt
Что из себя должен представлять агрегатор? Например есть логи iptables-а (байты,ip источника,ip получателя), можно еще время записать. Чтобы биллинг был горячим надо снимать данные и списывать деньги хотя бы раз в 15 минут (лучше каждые 5). Если использовать поток netflow, то почти тоже самое. Данные надо все равно скидывать достаточно часто в тарификатор. Тарификатором на мой взгляд должна быть БД с процедурами расчета.
В приведенной вами схемой не описана связь между загружателем в БД и тарификатором. Вопрос был именно в этом. Есть загружаемые данные и их нужно тарифицировать, так почему же их не тарифицировать сразу при добавлении, то есть триггером. Если сначала добавлять,а потом тарифицировать, то загрузка ведь не будет меньше?
Интересует именно вопрос тарификации загружаемых данных.

Агрегатор должен агрегировать трафик по портам, зонам, времени. Зависит от конкретного случая - какая информация для нас не актуальна. Допустим, если тарифицируем только _объем_ трафика _независимо от типа и зоны_ - можем выкинуть информацию по тому, на какой порт он приходил, на какой ip-адрес и когда (нам это абсолютно неважно для тарификации) и просто суммировать по всем портам за определенный промежуток времени - получаем реальное уменьшение входного потока в тарификатор.
Это лишь пример.

Тарификатором может быть приблуда написанная на C++ - совершенно не важно.

Важно лишь то, что данные должны загружаться максимально быстро.

И читать ты их должен максимально быстро, обрабатывая за раз как можно большее количество строк (в пределах разумного).

Если хочешь пользоваться триггерами - хорошо, ради бога. Кто же запрещает?
С PostgreSQL я не знаком, попробую рассказать в терминах Оракла.
Триггер должен быть не FOR EACH ROW. Триггер должен вызывать функции пакета, в котором будут закэшированны (тем или иным способом) тарифы.
Если ты уверен, что мощности и скорости встроенного языка в PostgreSQL хватит для такого делай - действуй.

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

Делиться вряд ли кто будет :)