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

Не спорю... может быть не оптимизированые алгоритмы и пр. не вникал, т.к. я не фанат MS и этот биллинг по любому бы не использовал.

>перезапуск тоже не нужен
>я когда в кейке процедуры отлаживал -- так и менял их по
>"горячему"

Я бы удивился бы, если бы надо было после переписки stored процедуры перезапускать радиус или СУБД.

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

Вот это точно бред. Обсчет ведется в модуле, а все данные беруться из базы. Готов спорить, что C'шный модуль по количеству операций в секунду сделает хранимую процедуру в разы.

>хм, в кейке скидывается по session-octets-limit вообще то, границы срабатывания как правило
>в пределах 0-30кб, какой точностью срабатывания может похвастаться ваш "волшебный скрипт"?

В моем случае это абсолютно бесполезно. session-octets-limit нельзя просчитать, т.к. в зависимости от времени суток цена на трафик меняется. Если мне препрет высокая точность я выставлю update interval в 1 минуту. На данный момент точности хватает, если буду пользовать netflow точность будет в вышеназваном Вами пределе. В cake придется чем-то жертвовать - или гибкостью тарифных планов или точностью расчета :)

>Да у меня на работе работает именно такой билинг. Тормозить начинает только
>когда данных скапливается более чем за полгода.

Осталось уточнить что за железо стоит у Вас на работе, т.к. MS обычно не стесняется в требованиях к железу.

>Слабая документация эта самая главная проблема open source проектов.
>На cake специально написана документация по шагам, чтобы меньше вопросов, при установке.

А с чего Вы взяли, что шаги сделаные Вами, приведут другого пользователя к желаемому результату? В nibs помоему есть тоже пошаговая инструкция, но вопросов от этого меньше не становиться.

>>куча вопросов, которые не будут освещены в Вашей доке.
>Начинай. ;)

Бессмысленно. В nibs все есть, так зачем же искать добро от добра?

>А что есть ядро база? Я думаю там мало, что осталось от
>FreeNIBS.

База - это всего лишь хранилище. Ядро биллинга - это его расчетная часть.

>С базой вы будете работать чистым SQL так ? Причем к запросам
>RADIUS'а добавятся запросы модуля на C. А далее эти SQL запросы

Какие запросы радиуса? nibs обращается к базе сам. freeradius в этом случае выступает в качестве посредника - получил список аттрибутов от NAS - отдал nibs'у, nibs сгенерил несколько аттрибутов, freeradius их запихнул в udp и отдал NAS'у.

>в базе сначала скомпилируются, а затем запустятся. Хранимая процедура компилируется один
>раз при создании, перекомпилируется при изменении. Далее хранится в скомпилированном виде
>и  просто вызывается. Т.е. вызов хранимой процедуры менее затратен чем
>чистый вызов SQL.

Да ну, а затратить время на вызов это процедуры (инициализация, обработка результата) - в результате получается не все так гладко. В твоем случае, если ты не претендуешь на ISP биллинг - SP пожалуй идеальный вариант.

>>точно Вам говорю. Нет смысла ставить для обсчет 10 пользователей Oracle
>Зависит от задач этих десяти пользователей. Если у них есть лишние 10
>тыщ баксов почему бы нет ?

Если у них не более 10-20 запросов к базе в минуту - точно говорю не стоит. 10k$ всегда можно потратить на что-то другое, ведь денег никогда много не бывает.

>>Стрельба из пушки по воробьям - это не есть гуд.
>Обоснуйте почему я должен использовать MySQL с SQL89, если использование PostgreSQL с
>SQL92 (хотя там не полная реализация) более целесобразно. Трудоемкость написания хранимой
>процедуры, ниже написания модуля на C или на Perl. К тому
>же компактнее и менее затратно по отношению к операционной системе.

Зависит от задач, которые выполняются. Сложность установки одного и другого приблизительно одинакова. MySQL быстрее отрабатывает на select и insert - поэтому я его юзаю для тарификации и сбора netflow, в Pg - я храню подсчитаный результат. Pg - более надежная штука при высоких нагрузках. Я понимаю Ваше желание после прослушивания крутого курса по СУБД писать все в SP, но поверьте - это не всегда круто и обосновано.

>Сложность настройки FreeNIBS проистекает от его архитектуры, а не его возможностей. Можно
>добавить в Cake теже фичи, что есть во FreeNIBS. Но сложность
>установки не возрастет. Более того изменятся только файлы схемы данных и
>интерфейсного модуля.

Ну и как же архитектура влияет на сложность настройки??? там есть два файлика один - дамп базы, второй модуль. В инструкции я нашел как прикрутить модуль к радиусу. Что еще надо? обладая минимальными знаниями nibs ты без труда прикрутишь и получишь в работу все функции, заявленные атвором. Вспоминается случай - общался с одним пользователям по аське - в итоге все свелось к тому что nibs дерьмо. На мой вопрос чем отличается select от insert он вразумительного ответа не дал. Большинство так называемых user'ов привыкли к удобному wizard'у и не привыкли даже бегло читать документацию.

>Вопрос какой волшебный скрипт ? checkrad.sh ? У него больше погрешность.
>И он запускается из cron'ом.

О чем я и говорил "привыкли к удобному wizard'у и не привыкли даже бегло читать документацию". checkrad - универсальный скрипт, написанный для многих типов NAS, который проверяет существование сессии данного пользователя. Я его не пользую. Написал свой, который ходит ко всем NAS'ам и как результат возвращает количество сессий, открытых заданным логином + закрывает зависшие сессии. Весь скрипт весит около 3кб и отлично работает уже больше года. Да, чуть не забыл - checkrad.pl запускается не из cron'а.