| 1.1, Dmitry (??), 15:55, 21/07/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 1 нет связей по таблица, трудно понять все. Тригерочками кое-что необходимо сделать, например лицевой счет изменять только по приходу/расходу.
Нужен email контактный по пользователю - автомтика рассылать сообщения будет, если уйдет клиент - можно продать спамерам ;-).
2 К счету привязываеться пользователь, он может получать услуги,для сего он может заводить отдельные логины (нексолько) и пароли. Управление счетом одно, потребление услуг - другое.
| | |
| |
| 2.3, gara (??), 16:50, 21/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
 >1 нет связей по таблица, трудно понять все. Тригерочками кое-что необходимо сделать,
А до про таблицы и тригерочки пока еще никто не говорил... это просто описание модели.
>
>2 К счету привязываеться пользователь, он может получать услуги,
для сего он может заводить отдельные логины (нексолько) и пароли.
А логины и пароли для чего?
>Управление счетом одно, потребление услуг - другое.
А что такое "счет" в вашем понимании?
| | |
|
| 1.2, Dmitry (??), 15:56, 21/07/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
3 Услуга
3.1 реакция системы на отключения от услуги, тоесть как прекратить потребление пользователем услуги - скрипт или что-то или ничего.
3.2 Услугу может быть свободно затребована или выдана администратором ( на всякий случай напишу)
3.3 Услуга может иметь временную функцию ( тарифы).
3.4 порог отключения по остатку денежных средств или кредит. (спорно на счет кредита, но корпоративных пользователей за 0 на счету рубить сразу нельзя, сильно обидятся)
4. Списание, только временной интервал и все ? Трафик ? Может добавить три параметра для учета нескольких параметров.(Тот же трафик внутри AS,РФ и международный). Возможно коснеться и изменеиях таблицы УСЛУГ.
Кто списал деньги - робот, человек, короче авторство - тригерром заполняем. запрещение UPDATE. Комментарии, причем может и пару, н куда кривая выведет - не ясно, пригодяться.
5. Платежи - тип платежа (из отдельной таблички), кто внес в DB, невозможен UPDATE, комментарии.
У бухгалтеров нужно уточнять.
НУ собственно хватит для начала. И не простое это дело. | | |
| |
| 2.4, gara (??), 16:52, 21/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>
>3 Услуга
>3.1 реакция системы на отключения от услуги, тоесть как прекратить потребление пользователем
>услуги - скрипт или что-то или ничего.
>
>3.2 Услугу может быть свободно затребована или выдана администратором ( на всякий
>случай напишу)
>3.3 Услуга может иметь временную функцию ( тарифы).
>3.4 порог отключения по остатку денежных средств или кредит. (спорно на счет
>кредита, но корпоративных пользователей за 0 на счету рубить сразу нельзя,
>сильно обидятся)
>
>4. Списание, только временной интервал и все ? Трафик ? Может добавить
>три параметра для учета нескольких параметров.(Тот же трафик внутри AS,РФ
>и международный).
Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если надо учитывает разные параметры и говорит билингу сколько надо списать. А за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно.
| | |
| |
| 3.8, Алексей (??), 03:15, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
 Списывать деньги с единого счета (лицевого счета клиента)
порочно.
Ибо клиент потребляющий у Вас разнородные услуги
(например хостинг и диалап) очень часто будет платить за каждую услугу отдельно (отдельным счетом или отдельной строккой в счете)
соответвенно (при едином счете на все усуги) рано или поздно
встанет вопрос сколько средств со счета можно израсходовать по тому
или другому сервису.
По простому можно под каждую услугу заводить отдельный лицевой счет.
можно же родить "аля" план счетов.
Кроме этого, в биллинге нужно предусмотреть диллеров/реселеров/партнеров
Ну и продвинутую подсистему отчетности нужно не забыть.
| | |
| |
| 4.12, gara (??), 10:14, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Списывать деньги с единого счета (лицевого счета клиента)
>порочно.
>Ибо клиент потребляющий у Вас разнородные услуги
>(например хостинг и диалап) очень часто будет платить за каждую услугу отдельно
>(отдельным счетом или отдельной строккой в счете)
>соответвенно (при едином счете на все усуги) рано или поздно
>встанет вопрос сколько средств со счета можно израсходовать по тому
>или другому сервису.
Может я неправильно назвал поняти.
Обясню по другому - счет клиента это грубо говоря сколько денег у него в билинге(положительных или отрицательных - долги) а при списании денег за услуги ведется список списанных средств - за эту услугу столько, за эту столько. Причем строка списания средств выглядит примерно так:
"дата_начала_оказания, дата_окончания_оказания, название услуги(хостинг|трафик|воис|) цена, колво , сумма"
>По простому можно под каждую услугу заводить отдельный лицевой счет.
>можно же родить "аля" план счетов.
>Кроме этого, в биллинге нужно предусмотреть диллеров/реселеров/партнеров
А можно поподробнее по этому вопросу? А нельзя диллеров также поместить как _КОНТРАКТ_ ? и прилепить им модуль-услугу реализуюущюю алгоритм для оптовых покупателей.
Или сделать еще одни тип контракта: "Диллер", т.е. контракт может быть след типов : "Физ лица", "Юр. лица", "Диллеры","служебные".
>Ну и продвинутую подсистему отчетности нужно не забыть.
Обязательно.
| | |
| |
| 5.16, Norguhtar (?), 15:46, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
 >Обясню по другому - счет клиента это грубо говоря сколько денег у
>него в билинге(положительных или отрицательных - долги) а при списании >денег за услуги ведется список списанных средств - за эту услугу столько,
>за эту столько. Причем строка списания средств выглядит примерно так:
>"дата_начала_оказания, дата_окончания_оказания, название услуги(хостинг|трафик|воис|) цена, колво , сумма"
>
А клиент желает чтобы на две машины было по лицевому счету. И чтобы заносить и расходовать деньги можно было отдельно на каждой машине. Теперь понятно?
Т.е. деньги должны привязываться к лицевому счету. Т.е. контракт один, но лицевых счетов много. К каждому из них можно привязывать одну и более услугу. | | |
| |
| 6.17, uldus (ok), 16:54, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>А клиент желает чтобы на две машины было по лицевому счету. И
>чтобы заносить и расходовать деньги можно было отдельно на каждой машине.
>Теперь понятно?
Насколько я помню, нам пришлось отказаться от старого биллинга по причине того, что много клиентов хотело чтобы деньги списывались за кучу услуг и логинов с _одного_ счета, т.е. из одного места.
>Т.е. деньги должны привязываться к лицевому счету. Т.е. контракт один, но лицевых
>счетов много.
Бухгалтерия выписывает всегда один счет на контракт, в котором просто расписывается/детализируется список услуг.
| | |
| |
| 7.22, gara (??), 17:46, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>>А клиент желает чтобы на две машины было по лицевому счету. И
>>чтобы заносить и расходовать деньги можно было отдельно на каждой машине.
>>Теперь понятно?
>
>Насколько я помню, нам пришлось отказаться от старого биллинга по причине того,
>что много клиентов хотело чтобы деньги списывались за кучу услуг и
>логинов с _одного_ счета, т.е. из одного места.
>
>>Т.е. деньги должны привязываться к лицевому счету. Т.е. контракт один, но лицевых
>>счетов много.
>
>Бухгалтерия выписывает всегда один счет на контракт, в котором просто расписывается/детализируется список
>услуг.
ВОТ ОНА ИСТИНА!!!!!
хотите списывать отдельно - отдельно разные контракты заводите!!!
| | |
| |
| |
| 9.26, uldus (ok), 22:21, 22/07/2004 [^] [^^] [^^^] [ответить] | +/– | А когда идет предоплата Как определите на какой лицевой счет сколько положить,... текст свёрнут, показать | | |
| |
| |
| 11.46, gara (??), 13:26, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | Тогда получается что к субсчетам прикрепляется 1 или несколько услуг В общем мо... текст свёрнут, показать | | |
| 11.67, uldus (ok), 22:33, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | У нас первая схема, но похожая на третью - Вместо субсчетов - лимиты по услуге... текст свёрнут, показать | | |
|
|
|
|
| 7.27, Norguhtar (?), 07:00, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Насколько я помню, нам пришлось отказаться от старого биллинга по причине того,
>что много клиентов хотело чтобы деньги списывались за кучу услуг и
>логинов с _одного_ счета, т.е. из одного места.
Эээ внимательно читаем. Если бы у вас была связь многие-ко многим. Т.е. к примеру на один лицевой счет можно привязать пачку услуг. И к нескольким лицевым счетам разные услуги... проблем бы вообще не возникало.
>Бухгалтерия выписывает всегда один счет на контракт, в котором просто расписывается/детализируется список
>услуг.
И еще дополнительно указывает лицевой счет. Хотя все деньги идут на один контракт. Просто добавляется еще одна связь, а выдавать и так и так легко.
| | |
| |
| 8.32, gara (??), 09:03, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | эээ может просто при генерации счетов сделать групировку разходов я всеравно не... текст свёрнут, показать | | |
| |
| |
| 10.51, gara (??), 14:46, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | ЛЕГКО Услуга такого типа трафик с включенными МБ цена за превышение - т е... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 3.10, Dmitry (??), 08:22, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если
>надо учитывает разные параметры и говорит билингу сколько надо списать. А
>за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно.
Когда вытсавляешь счет, лучше детализировать за какую услугу сколько платят.
Распечатка звонков, тот или иной трафик, итд итп.
| | |
| |
| 4.11, gara (??), 10:02, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>>Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если
>>надо учитывает разные параметры и говорит билингу сколько надо списать. А
>>за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно.
>
>Когда вытсавляешь счет, лучше детализировать за какую услугу сколько платят.
>Распечатка звонков, тот или иной трафик, итд итп.
Естественно. Только это должно быть реализованно не в ядре билинга в модуль-услуге. А в модуль-услугу можно напихать любую детализацию.
| | |
|
|
| 2.5, Norguhtar (?), 16:58, 21/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Кроме этого возможна реализация модулей НЕУСЛУГ.
>
>Например:
> - Пополнение счета с помощью различных платежных карт.
> - Экспорт данных в бухгалтерские программы и Execel.
> - Статистические, финансовые и аналитические отчеты.
> - и т.д.
сие скажем так сервисные вещи к Биллингу относится мало.
>Такая модульность позволяет менять "поведение" билинга, в зависимости от
>того какие модули и/или модуль - услуги подключены.
Модульность и гибкость структуры ограничена структурой базы СУБД.
Эээ а где все тоже, но в виде ER диаграммы. Плюс если не хочется гемороя MySQL как поддерживаемая СУБД присутвовать не должена. Поскольку эта СУБД не позволяет реализовывать хранимые процедуры. Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто. Чего хочется. Более подробного описания алгоритма, ER-диаграммы в 3 нормальной форме ;).
>Неотъемлемой частью билинга есть возможность пользователя управлять >контрактом.
>Подразумевает наличие интерфейса пользователя к своему контракту.
>Возможность вносить какие-то изменения. Например блокировать "элемент
>услуги". Отказываться от услуги. Менять услугу с одной на другую.
>"Покупать" услугу.
По SSL и пароль без причин менять нельзя. Еще лучше по ЭЦП чтоб заход был :) (по SSL сертификатам). По минимуму просмотр статистики. По максимуму добавление услуг.
По первому типу услуг ip-телефония dial-up карточки. Ноги должны расти от RADIUS. И мое ИМХО лучше использовать FreeRADIUS как бы не вопили из GPL радиусов. Это лучшее. | | |
| |
| 3.6, gara (??), 18:46, 21/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Модульность и гибкость структуры ограничена структурой базы СУБД.
>Эээ а где все тоже, но в виде ER диаграммы. Плюс если
>не хочется гемороя MySQL как поддерживаемая СУБД присутвовать не должена.
>Поскольку эта СУБД не позволяет реализовывать хранимые процедуры.
Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно подвесить базу.
>Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто.
Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок.
>Чего хочется. Более подробного описания алгоритма, ER-диаграммы в 3 нормальной форме ;).
более подробный алгоритм будет позже. Кстати можете присоедениться к его описанию...
>
>По первому типу услуг ip-телефония dial-up карточки. Ноги должны расти от RADIUS.
Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и поделиться с юлижним) модуль имеющий те или инные возможности и соответствующие интерфейсы.
| | |
| |
| 4.9, Norguhtar (?), 07:23, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно
>подвесить базу.
Нефиг зацикливаться. Правильно написанные процедуры работают быстрее внешних программных модулей в биллинге. Плюс перенос и модификация хранимых процедур проще чем перенос и модификация внешних программных модулей.
>>Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто.
>Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок.
См. как сделана реализация модулей SQL во FreeRADIUS. Все четко и легко меняется. И практически не зависит от СУБД
>более подробный алгоритм будет позже. Кстати можете присоедениться к его описанию...
Могу помочь с алгоритмами для первого типа услуг.
>Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и >поделиться с ближним) модуль имеющий те или инные возможности и >соответствующие интерфейсы.
Не совсем понятно. Единый будет продукт или солянка из пачки билингов ?
RADIUS собственно предназначен именно для авторизации и акакунтинга dialup в дальнейшем его возможности хорошо подошли к VPN и VoIP. Реализация самой процедуры сбора проста. Проблема только это все потом обработать :)
| | |
| |
| 5.13, ggv (?), 10:15, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>RADIUS собственно предназначен именно для авторизации и акакунтинга dialup в дальнейшем его
>возможности хорошо подошли к VPN и VoIP. Реализация самой процедуры сбора
>проста.
Is it so? Imagine - there are several cisco VoIP GW all over internet, each one with several radius servers in the same LAN or even in the same switch with cisco.
And there is a single storage.
One task is to collect accounting info from all radiuses.
Second task is to supply the info for authentication.
If to connect each radius server as a client directly to the remote single storage (whatever it is, directory or a database) we may forget about reliability... Internet is not reliable by definition. New Year night traffic, and so on, different problems ith viruses like Slammer...
There are some others reasons.
| | |
| 5.14, gara (??), 10:21, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>>Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно
>>подвесить базу.
>Нефиг зацикливаться. Правильно написанные процедуры работают быстрее внешних программных модулей в биллинге.
>Плюс перенос и модификация хранимых процедур проще чем перенос и модификация
>внешних программных модулей.
Это еще как сказать...
Если изначально писать под MySQL то работать будет на любой СУБД.
А если использовать хранимые процедуры то чтоб перенести придется переписывать весь синтаксис. Алгоритм да останется, но синтаксис ой как будет отличаться....
>
>>>Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто.
>>Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок.
>См. как сделана реализация модулей SQL во FreeRADIUS. Все четко и легко
>меняется. И практически не зависит от СУБД
Несомневаюсь что все легко потомучто sql запросы сделаны универсальными, даже упращенными - для mysql (потому как ИМХО проще некуда).
>
>>более подробный алгоритм будет позже. Кстати можете присоедениться к его описанию...
>Могу помочь с алгоритмами для первого типа услуг.
Буду рад.
На днях откроется сайт под это дело и там можно будет это дело выкладывать - обсуждать.
>>Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и >поделиться с ближним) модуль имеющий те или инные возможности и >соответствующие интерфейсы.
>Не совсем понятно. Единый будет продукт или солянка из пачки билингов ?
>
Единым будет ядро, + солянка модуль-услуг, и доп модулей.
| | |
| |
| |
| 7.18, ggv (?), 16:58, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>работы процедуры. Сколько раз можно повторять вся бизнес логика должна быть
>внутри базы, а не снаружи.
It's not a final truth.
It's just one point of view only.
Correct would be to say "a business logic may be inside of a database", because statement about 'must be' is not proved. yet.
| | |
| |
| 8.21, gara (??), 17:30, 22/07/2004 [^] [^^] [^^^] [ответить] | +/– | Пишите по русски латиницей плиз, если русских клавишь нету не все владеют англ... текст свёрнут, показать | | |
| |
| 9.25, ggv (?), 19:11, 22/07/2004 [^] [^^] [^^^] [ответить] | +/– | Sorry, I can t I remember all russian keys position, I just don t have russian ... текст свёрнут, показать | | |
|
| |
| 9.37, ggv (?), 11:37, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | Sorry, but it s wrong Pleasey, when you make such statement, ad what database h... текст свёрнут, показать | | |
|
|
| 7.19, ggv (?), 17:07, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Ядро любого билинга это БАЗА. Все остальное не важно.
Not always. It might be a combination of a database and a directory.
And such combination usualy has many advantages, if to compare with solution on a datbase only.
| | |
| |
| |
| 9.38, ggv (?), 11:38, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | It s a common mistake of many people Good LDAP server implementation can do MUC... текст свёрнут, показать | | |
| |
| |
| 11.57, ggv (?), 15:17, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | It s exactly what I meant when told about common mistake If you hear ldap - it ... текст свёрнут, показать | | |
|
|
|
|
| 7.20, gara (??), 17:28, 22/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>>>Плюс перенос и модификация хранимых процедур проще чем перенос и модификация
>>>внешних программных модулей.
>>Это еще как сказать...
>>Если изначально писать под MySQL то работать будет на любой СУБД.
>Спасибо MySQL даже не вчерашний а позавчерашний день он соответсвует спецификации SQL89,в
>нем нет хранимых процедур. Равняться на нее в связи с тем
>что она проста для освоения и переноса не стоит, если в
>проекте по умлчанию используется MySQL или поддерживается я не буду даже
>рассматривать этот проект. Поверь гараздо проще изменить логику работы SQL процедуры
>чем лопатить код внешних процедур на C или C++. Это может
>сделать и субд деволпер причем так как что изменит всю логику
>работы процедуры.
Возможно вы правы.
>Сколько раз можно повторять вся бизнес логика должна быть внутри базы, а не снаружи.
Спорно. Если у нас клиент-сервер то да. Данные хранятся а БД, логика в хранимых процедурах. Клиен - отображает данные и делает запрос на расчет того или иного с помощю хранимых процедур + клиент сам чегото считает. Хранимые процедуры в данном случае сильно экономят трафик.
Если же используется 3_х уровневая архитектура ТО -
1. БД хранит только данные.
2. Сервер "приложений"(в нашем случае скрипты) берет данные из БД считает, умножает делит и т.д. и результаты записывает в БД.
3. Клиент (броузер или win приложение) работает как терминал - посмотреть, изменить, добавить/удалить и ВСЕ.
Все считают скрипты, на чем они написанны - второе дело.
>>Единым будет ядро, + солянка модуль-услуг, и доп модулей.
>Что есть ядро ? И модули-услуг и доп. модули?
>Ядро любого билинга это БАЗА. Все остальное не важно.
Сегодня накропаю продолжение статиь либо подождем пока запущу сайт.
| | |
| |
| |
| 9.31, gara (??), 08:59, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | Я описал ксасическую 3_х уровневую архитектуру БД-сервер приложений-клиент Кр... текст свёрнут, показать | | |
| |
| 10.39, ggv (?), 11:45, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | Definitely Norguhtar has a little knowledge about 3-tier architecture But it s ... текст свёрнут, показать | | |
| |
| 11.55, gara (??), 15:03, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | Во первых она была разработана гораздо позже чем появились всякие нормальные БД... текст свёрнут, показать | | |
| |
| |
| 13.64, ggv (?), 16:21, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | That s wrong again And - don t forget the modern software can be modular Plug... текст свёрнут, показать | | |
| 13.65, ggv (?), 16:27, 23/07/2004 [^] [^^] [^^^] [ответить] | +/– | Look at TPC-C Its task has nothing to do with Типа форумов и гостевух Проще го... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
|
| 1.24, Jaguar (??), 18:44, 22/07/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Самое прикольное - то что оплату проще всего интерпретировать как один из сервисов. | | |
| 1.33, Dmitry (??), 09:05, 23/07/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я бы еще предложил ввести таблицу с текущим потребленим и систему отслеживания сеанса потребления. Начало потребления, продолжение потребления ( сравнение потребления с остатком на счету ), конец потребления ( списываем деньги со счета)
1) Radius может использоваться для регулярных запросов на подтверждение полномочий потребления услуги. Тоесть идет постоянный контроль за наличием денег на счету.
2) Постоянное снятие денег со счета(например раз в минуту) приведет к слишком большому количеству записей, в принципе потом базу можно подчистить, но надо иметь ввиду.
3) таблица будет явно меньше таблицы всех пользователей, много из которых могут быть мертвыми.
4) Мониторинг потребителей.
Всегда можно пределать упрощенный сеанс потребления, стар и стоп.
Но закрывание услуги по радиусу сразу после опустошения счета крайне необходимо.
Плюсом даже не Radius, а например подсчет IP для выделенки тоже лучше делать в реальном времени, а в итоги за день заносить одной записью.
Возникает ряд проблем: потребление нескольких сервисов одновременно, перевод денег на счет в момент потребления. Но это не смертельно: суммируешь все потребление по таблице текущего потребления и сравниваешь со счетом, в случае конца потребления можешь все заново пересчитать, можешь перенести запись из текущего потребление. Варианты.
Использование храниых процедур - необходимость. Использование БД как тупого хранилища создаст больше проблем.
| | |
| |
| 2.35, gara (??), 11:04, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Использование храниых процедур - необходимость.
В чем выражается эта необходимость... обясните... только подругому а не так как было написанно выше.
>Использование БД как тупого хранилища создаст больше проблем.
Например?
| | |
| |
| 3.41, Dmitry (??), 12:09, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>В чем выражается эта необходимость... обясните... только подругому а не так как
>было написанно выше.
>
Самое простое: манипуляция денгами на счете.
Пришли деньги, бухгалтер или некий WebMoneyBot должен добавить денег на счет - НЕТ. Он просто должен создать приходную запись, далее деньги на счет падают хранимой процедурой. Тоже самое и с потреблением.
НИКАКИХ ПРЯМЯХ ИЗМЕНЕНИЙ состояния счета , только через табицу поступления или/и списывания денег. Все остальное от лукавого.
Я писал систему интеграции биллинга ISP с метной система банкоматов, коммуникационную часть. Мне дали только INSERT в одну таблицу, пару раз ткнули носом в ошибки , я поправил код и легко прибил навороченное ранее , добавив компенсирующие записи в туже таблицу с соотвествующими комментаримя . Так что идея не моя, а надежностью и защищенностью такой схемы я остался доволен.
Даже если у Вас ( как и у меня) есть трудности в написании хранимой процедуры - это не повод отказаться от такого простого и надежного механизма управления счетом. Я всегда прошу помощи в таких делах, не потому что дурак, а потому что это мне нужно крайне редко.
Согласен, не стоит завышать требования к возможностям БД, но и мириться с серьезными недостатками какой-либо из них крайне вредно.
Увеличение нагрузки - едва ли это вызовет.
| | |
| |
| 4.43, gara (??), 13:17, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>>В чем выражается эта необходимость... обясните... только подругому а не так как
>>было написанно выше.
>>
>Самое простое: манипуляция денгами на счете.
>Пришли деньги, бухгалтер или некий WebMoneyBot должен добавить денег на счет -
>НЕТ. Он просто должен создать приходную запись, далее деньги на счет
>падают хранимой процедурой. Тоже самое и с потреблением.
>НИКАКИХ ПРЯМЯХ ИЗМЕНЕНИЙ состояния счета , только через табицу поступления или/и списывания
>денег. Все остальное от лукавого.
В этом случае использование хранимой процедуры оправдано.согласен.
Дальше... еще примеры.
| | |
| |
| 5.60, Dmitry (??), 15:26, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>В этом случае использование хранимой процедуры оправдано.согласен.
>Дальше... еще примеры.
Больше примеров нет, чтобы на 100 быть увереным в необходимости.
Например прекращение потребления сервиса может происходить и в результате запуска хранимой процедуры + system, это чтобы раз в минуту не пробегать по базе в поисках нулей. Но тут много вариантов обойтись. Надо думать, что и как проще. Может опционально и не похо предусмотреть.
| | |
|
| 4.45, ggv (?), 13:23, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
Ok, then let count UDF and triggers together with SP.
And, let come one level up.
Because if it could be implemented in different, but reliable way, let don't speak about SP only, or UDF only, or trigger only.
Let speak about server-side routines.
Implementation will depend from a database capability and from exact needs.
Agreed?
| | |
| |
| 5.49, Emiljan (?), 14:24, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Let speak about server-side routines.
>Implementation will depend from a database capability and from exact needs.
>Agreed?
Fully.
Anyhow billing system complexity is prerogative of maintenance side.
Look at majors in this business. Noone is affected towards vendor/platform/dbms/environment. Moreover, in most cases multisupplier implementation occurs. There're narrow branches where relational db doesn't satisfy the requirements or businesslogic cannot be realized on server-side completely..
PS By the way does MySQL R5 supports SP & triggers? | | |
|
|
|
| 2.40, ggv (?), 12:06, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>1) Radius может использоваться для регулярных запросов на подтверждение полномочий потребления услуги.
>Тоесть идет постоянный контроль за наличием денег на счету.
Also NAS can request a max session time a client allowed to use and disconnect him after that time.
>2) Постоянное снятие денег со счета(например раз в минуту) приведет к слишком
>большому количеству записей, в принципе потом базу можно подчистить, но надо
>иметь ввиду.
If NAS requested a max session time we won't have such case.
At least we use it with cisco.
>Использование храниых процедур - необходимость. Использование БД как тупого хранилища создаст больше
>проблем.
That's strange and is not correct statement.
| | |
| |
| 3.42, Dmitry (??), 12:35, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>>1) Radius может использоваться для регулярных запросов на подтверждение полномочий потребления услуги.
>>Тоесть идет постоянный контроль за наличием денег на счету.
>Also NAS can request a max session time a client allowed to
>use and disconnect him after that time.
>
Это первое, что лезет в голову, НО проблема в тарифах, зависящих от времени суток и дня недели. Экстраполировать вперед по времени - слишком трудно и не красиво.
А если тариф зависит и от времени и от трафика?
А если несколько сервисов кормиться с одного счета?
А если один сервис менее критичен к перебору потребления, другой более.
А если во время потребления услуги был перевод денег, разорвем по старой сумме. Извинимся ? итд итп.
Посему отслеживания полномочий потребления должно проходить в реальном времени. Функция предсказывания может где-то и потребуется, но пока не вижу где.
>
>>Использование храниых процедур - необходимость. Использование БД как тупого хранилища создаст больше
>>проблем.
>That's strange and is not correct statement.
Погорячился, с кем не бывает ;-).
| | |
| |
| 4.44, ggv (?), 13:20, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Это первое, что лезет в голову, НО проблема в тарифах, зависящих от
>времени суток и дня недели. Экстраполировать вперед по времени - слишком
>трудно и не красиво.
>А если тариф зависит и от времени и от трафика?
>А если несколько сервисов кормиться с одного счета?
>А если один сервис менее критичен к перебору потребления, другой более.
>А если во время потребления услуги был перевод денег, разорвем по старой
> сумме. Извинимся ? итд итп.
>Посему отслеживания полномочий потребления должно проходить в реальном времени.
These all are correct for post-paid. Sure.
Функция предсказывания может
>где-то и потребуется, но пока не вижу где.
Pre-paid services.
| | |
| |
| 5.56, Dmitry (??), 15:13, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>These all are correct for post-paid. Sure.
post-paid после, или я не правильно понял (может лучше в транслите написать)?
Но потребление услуги идет в текущий момент, так что с префиксом post не согласен, Я просто подтверждаю или нет последуещее потребление услуги, до следующего запроса. Такой метод универсальный. Совершенно не нужна экстраполяция по времени, нужна стоиомсть услуги в текущий момент.
| | |
| |
| 6.59, ggv (?), 15:25, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
post-paid service is based on a kredit, on an account. A customer works an amount of time, service supplier issue an invoice, the customer paid according the invoice for already consumed service.
But does not matter - could be more variants. Between service supplier and customer.
And all schemas of work with radius could be in use. | | |
|
|
| 4.52, Norguhtar (?), 14:49, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Это первое, что лезет в голову, НО проблема в тарифах, зависящих от
>времени суток и дня недели. Экстраполировать вперед по времени - слишком
>трудно и не красиво.
Ничего сложного и некрасивого не вижу легко реализуется хранимой процедурой.
>А если тариф зависит и от времени и от трафика?
Тут да косяк. Не все NAS умеют обращаться еще раз к RADIUS. Учитывайте что RADIUS умеет авторизовать и учитывать. При учете reply не отдаются только при авторизации.
>А если во время потребления услуги был перевод денег, разорвем по старой
> сумме. Извинимся ? итд итп.
Да тут будет внешная процедура... :)
| | |
| |
| 5.61, Dmitry (??), 15:42, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>>А если тариф зависит и от времени и от трафика?
>Тут да косяк. Не все NAS умеют обращаться еще раз к RADIUS.
>Учитывайте что RADIUS умеет авторизовать и учитывать. При учете reply не
>отдаются только при авторизации.
Если уж так приперло, можно периодически обстукивать по SNMP устройства и определять трафик или сшибать с NAS пользователя. Но все это кривовато, и опчть же - а позволит ли NAS делать ЭТО.
Если нет - на помойку или не выдавать тарифы с трафиком.
| | |
| |
| 6.63, Norguhtar (?), 15:58, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>>>А если тариф зависит и от времени и от трафика?
>>Тут да косяк. Не все NAS умеют обращаться еще раз к RADIUS.
>>Учитывайте что RADIUS умеет авторизовать и учитывать. При учете reply не
>>отдаются только при авторизации.
>Если уж так приперло, можно периодически обстукивать по SNMP устройства
>и определять трафик или сшибать с NAS пользователя. Но все это
>кривовато, и опчть же - а позволит ли NAS делать ЭТО.
Либо сделать фиксированную скорость канала ;) Тогда рубить по количеству трафика легко. ;) Нуу а тут много всяких но есть :)
| | |
|
| 5.66, ggv (?), 18:19, 23/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Учитывайте что RADIUS умеет авторизовать и учитывать. При учете reply не
>отдаются только при авторизации.
That's wrong. Radius send reply on each accounting request.
Here is a debug output of a server (freeradius):
modcall: entering group accounting for request 1
modcall[accounting]: module "mq" returns ok for request 1
modcall: group accounting returns ok for request 1
Sending Accounting-Response of id 39 to 127.0.0.1:33211
Finished request 1
And here is a log from the client for this request:
rad_recv: Accounting-Response packet from host 127.0.0.1:1813, id=230, length=20 | | |
| |
| 6.68, gvf (?), 23:40, 24/07/2004 [^] [^^] [^^^] [ответить]
| +/– |
мда-а-а, с интересом прочитал все сообщения....
очень много правильного, НО - возникло ощущение что все участники
тянут каждый в свою сторону (имея в виду свои собственные задачи и условия). Другими словами - нет четкого определения поставленной задачи (т.е. тех. задания).
Автор просто описал некую виртуальную структуру (вероятно с целью получше
разобраться в предмете, прежде всего для себя...) никакого отношения к реальной жизни не имеющую.
вывод: вы сначала ТЗ напишите, а потом уже обсуждайте методы наилучшего
решения.
| | |
|
|
|
|
|
|
