>>Плюс перенос и модификация хранимых процедур проще чем перенос и модификация
>>внешних программных модулей.
>Это еще как сказать...
>Если изначально писать под MySQL то работать будет на любой СУБД.
Спасибо MySQL даже не вчерашний а позавчерашний день он соответсвует спецификации SQL89,в нем нет хранимых процедур. Равняться на нее в связи с тем что она проста для освоения и переноса не стоит, если в проекте по умлчанию используется MySQL или поддерживается я не буду даже рассматривать этот проект. Поверь гараздо проще изменить логику работы SQL процедуры чем лопатить код внешних процедур на C или C++. Это может сделать и субд деволпер причем так как что изменит всю логику работы процедуры. Сколько раз можно повторять вся бизнес логика должна быть внутри базы, а не снаружи.

>А если использовать хранимые процедуры то чтоб перенести придется >переписывать весь синтаксис.
А если переносить внешние процедуры на C на другую *nix платформу или архитектуру мы получим возможные проблемы. При переносе же СУБД с базой содержащей хранимые процедуры на другую платформу или архитектуру это уже проблемы разработчиков СУБД, а не наши.

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

>Несомневаюсь что все легко потомучто sql запросы сделаны универсальными, >даже упращенными - для mysql (потому как ИМХО проще некуда).
Там сделано проще. Там выполняются просто SQL запросы. Т.е. что вы там скормите это на вашей совести. Но все операции accounting конечно ориентированы на insert и update.

>На днях откроется сайт под это дело и там можно будет это
>дело выкладывать - обсуждать.
Ждемс. Поделюсь что умеет ppp + radius ;)

>Единым будет ядро, + солянка модуль-услуг, и доп модулей.
Что есть ядро ? И модули-услуг и доп. модули?
Ядро любого билинга это БАЗА. Все остальное не важно. Пока нет ТЗ и эскиза базы... О ядре говорить рано. Можно лишь наметить какие виды информации будут заноситься о пользователе.