The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

OpenNews: Структура открытой системы биллинга, opennews (??), 21-Июл-04, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


2. "Структура открытой системы биллинга"  +/
Сообщение от Dmitryemail (??), 21-Июл-04, 15:56 

3 Услуга
3.1 реакция системы на отключения от услуги, тоесть как прекратить потребление пользователем услуги - скрипт или что-то или ничего.

3.2 Услугу может быть свободно затребована или выдана администратором ( на всякий случай напишу)
3.3 Услуга может иметь временную функцию ( тарифы).
3.4 порог отключения по остатку денежных средств или кредит. (спорно на счет кредита, но корпоративных пользователей за 0 на счету рубить сразу нельзя, сильно обидятся)

4. Списание, только временной интервал и все ? Трафик ? Может добавить три  параметра для учета нескольких параметров.(Тот же трафик внутри AS,РФ и международный). Возможно коснеться и изменеиях таблицы  УСЛУГ.
Кто списал деньги - робот, человек, короче авторство - тригерром заполняем.  запрещение UPDATE. Комментарии, причем может и пару, н куда кривая выведет - не ясно, пригодяться.
5. Платежи - тип платежа (из отдельной таблички), кто внес в DB, невозможен UPDATE, комментарии.
У бухгалтеров нужно уточнять.

НУ собственно хватит для начала. И не простое это дело.

Ответить | Правка | Наверх | Cообщить модератору

4. "Структура открытой системы биллинга"  +/
Сообщение от garaemail (??), 21-Июл-04, 16:52 
>
>3 Услуга
>3.1 реакция системы на отключения от услуги, тоесть как прекратить потребление пользователем
>услуги - скрипт или что-то или ничего.
>
>3.2 Услугу может быть свободно затребована или выдана администратором ( на всякий
>случай напишу)
>3.3 Услуга может иметь временную функцию ( тарифы).
>3.4 порог отключения по остатку денежных средств или кредит. (спорно на счет
>кредита, но корпоративных пользователей за 0 на счету рубить сразу нельзя,
>сильно обидятся)
>
>4. Списание, только временной интервал и все ? Трафик ? Может добавить
>три  параметра для учета нескольких параметров.(Тот же трафик внутри AS,РФ
>и международный).

Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если надо учитывает разные параметры и говорит билингу сколько надо списать. А за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно.

Ответить | Правка | Наверх | Cообщить модератору

8. "Структура открытой системы биллинга"  +/
Сообщение от Алексейemail (??), 22-Июл-04, 03:15 
Списывать деньги с единого счета (лицевого счета клиента)
порочно.
Ибо клиент потребляющий у Вас разнородные услуги
(например хостинг и диалап) очень часто будет платить за каждую услугу отдельно (отдельным счетом или отдельной строккой в счете)
соответвенно (при едином счете на все усуги) рано или поздно
встанет вопрос сколько средств со счета можно израсходовать по тому
или другому сервису.
По простому можно под каждую услугу заводить отдельный лицевой счет.
можно же родить "аля" план счетов.
Кроме этого, в биллинге нужно предусмотреть диллеров/реселеров/партнеров
Ну и продвинутую подсистему отчетности нужно не забыть.
Ответить | Правка | Наверх | Cообщить модератору

12. "Структура открытой системы биллинга"  +/
Сообщение от gara (??), 22-Июл-04, 10:14 
>Списывать деньги с единого счета (лицевого счета клиента)
>порочно.
>Ибо клиент потребляющий у Вас разнородные услуги
>(например хостинг и диалап) очень часто будет платить за каждую услугу отдельно
>(отдельным счетом или отдельной строккой в счете)
>соответвенно (при едином счете на все усуги) рано или поздно
>встанет вопрос сколько средств со счета можно израсходовать по тому
>или другому сервису.

Может я неправильно назвал поняти.
Обясню по другому - счет клиента это грубо говоря сколько денег у него в билинге(положительных или отрицательных - долги) а при списании денег за услуги ведется список списанных средств - за эту услугу столько, за эту столько. Причем строка списания средств выглядит примерно так:
"дата_начала_оказания, дата_окончания_оказания, название услуги(хостинг|трафик|воис|) цена, колво , сумма"

>По простому можно под каждую услугу заводить отдельный лицевой счет.
>можно же родить "аля" план счетов.
>Кроме этого, в биллинге нужно предусмотреть диллеров/реселеров/партнеров
А можно поподробнее по этому вопросу? А нельзя диллеров также поместить как _КОНТРАКТ_ ? и прилепить им модуль-услугу реализуюущюю алгоритм для оптовых покупателей.
Или сделать еще одни тип контракта: "Диллер", т.е. контракт может быть след типов : "Физ лица", "Юр. лица", "Диллеры","служебные".
>Ну и продвинутую подсистему отчетности нужно не забыть.
Обязательно.


Ответить | Правка | Наверх | Cообщить модератору

16. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 22-Июл-04, 15:46 
>Обясню по другому - счет клиента это грубо говоря сколько денег у
>него в билинге(положительных или отрицательных - долги) а при списании >денег за услуги ведется список списанных средств - за эту услугу столько,
>за эту столько. Причем строка списания средств выглядит примерно так:
>"дата_начала_оказания, дата_окончания_оказания, название услуги(хостинг|трафик|воис|) цена, колво , сумма"
>
А клиент желает чтобы на две машины было по лицевому счету. И чтобы заносить и расходовать деньги можно было отдельно на каждой машине. Теперь понятно?
Т.е. деньги должны привязываться к лицевому счету. Т.е. контракт один, но лицевых счетов много. К каждому из них можно привязывать одну и более услугу.
Ответить | Правка | Наверх | Cообщить модератору

17. "Структура открытой системы биллинга"  +/
Сообщение от uldus (ok), 22-Июл-04, 16:54 
>А клиент желает чтобы на две машины было по лицевому счету. И
>чтобы заносить и расходовать деньги можно было отдельно на каждой машине.
>Теперь понятно?

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

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

Бухгалтерия выписывает всегда один счет на контракт, в котором просто расписывается/детализируется список услуг.

Ответить | Правка | Наверх | Cообщить модератору

22. "Структура открытой системы биллинга"  +/
Сообщение от garaemail (??), 22-Июл-04, 17:46 
>>А клиент желает чтобы на две машины было по лицевому счету. И
>>чтобы заносить и расходовать деньги можно было отдельно на каждой машине.
>>Теперь понятно?
>
>Насколько я помню, нам пришлось отказаться от старого биллинга по причине того,
>что много клиентов хотело чтобы деньги списывались за кучу услуг и
>логинов с _одного_ счета, т.е. из одного места.
>
>>Т.е. деньги должны привязываться к лицевому счету. Т.е. контракт один, но лицевых
>>счетов много.
>
>Бухгалтерия выписывает всегда один счет на контракт, в котором просто расписывается/детализируется список
>услуг.


ВОТ ОНА ИСТИНА!!!!!

хотите списывать отдельно - отдельно разные контракты заводите!!!

Ответить | Правка | Наверх | Cообщить модератору

23. "Структура открытой системы биллинга"  +/
Сообщение от Алексей (??), 22-Июл-04, 18:18 
>>>Т.е. деньги должны привязываться к лицевому счету. Т.е. контракт один, но лицевых
>>>счетов много.
>>
>>Бухгалтерия выписывает всегда один счет на контракт, в котором просто расписывается/детализируется список
>>услуг.
>
>
>ВОТ ОНА ИСТИНА!!!!!
>
>хотите списывать отдельно - отдельно разные контракты заводите!!!

Истана как всегда по середине.
Попросите как нибуть бухов показать оборотно сальдовую ведость
или план счетов.

p.s. Собрать несколько счетов в один вирутальный проще чем один счет разбить на несколько. Гланое не забыть пользователю дать право переводить
средства с одного своего счета на другой (скажем так с услуги на услугу) в рамках своего договора.
Главное скажем так, что бы дебет с кредитом сошелся

Ответить | Правка | Наверх | Cообщить модератору

26. "Структура открытой системы биллинга"  +/
Сообщение от uldus (ok), 22-Июл-04, 22:21 
>p.s. Собрать несколько счетов в один вирутальный проще чем один счет разбить

А когда идет предоплата ? Как определите на какой лицевой счет сколько положить, когда в присланной платежке только цена за все услуги в сумме ?


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

Это как предложить пользователю за колбасу и сыр расплачиваться с разных кредиток.
Большинству пользователям как настроят, так и поедет. Кроме как нажимать на несколько кнопок они не умеют. Большинство никогда не полезут что-то куда-то переводить, а в офис ходить по мелочам - проще другого провайдера найти.

Ответить | Правка | Наверх | Cообщить модератору

36. "Структура открытой системы биллинга"  +/
Сообщение от Алексей (??), 23-Июл-04, 11:09 
Предоплата за что? Как я могу угадать что клиент
потребляющий у меня комплексно 5-6ть услуг
оплатил одну услугу на 1месяц, а остальные на 3три?
Все равно ему прийдется пообщаться с манагерами и бухами.
А для особо ленивых клиентов ставится галка - распредилять средства по счетам услуг автоматически.


Относительно кредиток Вы не правы и колбасы не удачный пример.
Вернее пример удачный, но вывод из него несовсем правильный.
Если по договору клиент у нас покупает и сыр и колбасу нужно
ему дать возможность оплатить/купить не только и сыр и колбасу
одновременно, но и поотдельности.
Теперь как все это реализовывается в рамках уже высказанных идей.
1) Общий счет на все + один контракт - клиент загоняет деньги
  потом получает на складе колбасу и сыр пока не счете есть деньги
2) N счетов + N контратков - клиет за колбасу и за сыр платит
  отдельно (разными кредитками)
3) Общий счет + субсчета + один контракт - клиент платит скопом.
  при этом если клиент не указывает за что именно он платит
  деньги оседают на общем счете и могут расходоваться и на сыр и на колбасу.
  При этом клиенту оставляется возможность сразу распределить средства
на сыр и колбасу (указать целевое назначение средств), а в последвии перераспределить.

  Вот собственно 3ю схему хранения средств я и пропагандирую.

Ответить | Правка | Наверх | Cообщить модератору

46. "Структура открытой системы биллинга"  +/
Сообщение от garaemail (??), 23-Июл-04, 13:26 
>3) Общий счет + субсчета + один контракт - клиент платит скопом.
>  при этом если клиент не указывает за что именно он платит
>  деньги оседают на общем счете и могут расходоваться и на сыр и на колбасу.
>  При этом клиенту оставляется возможность сразу распределить средства
>на сыр и колбасу (указать целевое назначение средств), а в последвии перераспределить.
>  Вот собственно 3ю схему хранения средств я и пропагандирую.

Тогда получается что к субсчетам прикрепляется 1 или несколько услуг.
В общем можно реализовать такую схему. при добалении услуги - она привязывается к корневому счету или можно сразу выбрать суб счет.

Такой вопрос субсчета должны както именноваться? или могут просто нумероваться 1,2,3,4 и т.д.

Ответить | Правка | Наверх | Cообщить модератору

53. "Структура открытой системы биллинга"  +/
Сообщение от Алексей (??), 23-Июл-04, 15:00 
>>  Вот собственно 3ю схему хранения средств я и пропагандирую.
>
>Тогда получается что к субсчетам прикрепляется 1 или несколько услуг.
>В общем можно реализовать такую схему. при добалении услуги - она привязывается
>к корневому счету или можно сразу выбрать суб счет.
>
>Такой вопрос субсчета должны както именноваться? или могут просто нумероваться 1,2,3,4 и
>т.д.

Опять истина где-то по середине :)

IMHO самая дельная реализация хранилища информации о деньгах клиента
на услуги это план счетов (придумано давно и не мною)

План счетов это некотороя древовидная иерахия.
Наример так.
В корне номер контракта, далее ветки со счетами разных услуг.
N(xxx)
+-Diaup(10)
|   +-  dialup_account_id(1)
|              +- налик (1)
|              +- безнал (2)
|              +- бонусы (3)
|
+-Hosting(20)
    +-  virtualserver_id(1)
               +- налик (1)
               +- безнал (2)
               +- бонусы (3)
    +-  virtualserver_id(2)
               +- налик (1)
               +- безнал (2)
               +- бонусы (3)

Кадый узел дерево и его листок содержит
поля дебет/кредит

На субсчете с номером xxx.10.1.1 - содержится инфа о деньгах
клиента поступившим от него в наличной форме оплаты и т.д.

Самый важный "финт" это то что
дебет(xxx.20.1) = дебет(xxx.20.1.1) + дебет(xxx.20.1.2) + дебет(xxx.20.1.3)
дебет(xxx.20.2) = дебет(xxx.20.2.1) + дебет(xxx.20.2.2) + дебет(xxx.20.2.3)

и следом

дебет(xxx.20) = дебет(xxx.20.1) + дебет(xxx.20.2)

ну и немаловажным является то, что собственно таблицы (account_number, amount) нет,
а есть таблица операции над счетами и есить функция "СкокаСкока", которая дает ответ
сколько денег(условных попугаев) на том или другом счету имеется на тот или иной
момент времени.


Ответить | Правка | Наверх | Cообщить модератору

67. "Структура открытой системы биллинга"  +/
Сообщение от uldus (ok), 23-Июл-04, 22:33 
>3) Общий счет + субсчета + один контракт - клиент платит скопом.
>  Вот собственно 3ю схему хранения средств я и пропагандирую.

У нас первая схема, но похожая на третью :-) Вместо субсчетов - лимиты по услуге. По такой-то улуге разрешено проработать N часов, потратить M мегобайт и так далее. Для услуг с единовременным списанием стредств (диалап анлимит, хостинг, выделенки с абон. платой), субсчета только запутают все. Детализация дебит/кредит проводится по истории платежей, что позволяет посмотреть состояние "субсчета" за любой период.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

27. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 23-Июл-04, 07:00 
>Насколько я помню, нам пришлось отказаться от старого биллинга по причине того,
>что много клиентов хотело чтобы деньги списывались за кучу услуг и
>логинов с _одного_ счета, т.е. из одного места.
Эээ внимательно читаем. Если бы у вас была связь многие-ко многим. Т.е. к примеру на один лицевой счет можно привязать пачку услуг. И к нескольким лицевым счетам разные услуги... проблем бы вообще не возникало.


>Бухгалтерия выписывает всегда один счет на контракт, в котором просто расписывается/детализируется список
>услуг.
И еще дополнительно указывает лицевой счет. Хотя все деньги идут на один контракт. Просто добавляется еще одна связь, а выдавать и так и так легко.


Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

32. "Структура открытой системы биллинга"  +/
Сообщение от gara (??), 23-Июл-04, 09:03 
>>Насколько я помню, нам пришлось отказаться от старого биллинга по причине того,
>>что много клиентов хотело чтобы деньги списывались за кучу услуг и
>>логинов с _одного_ счета, т.е. из одного места.
>Эээ внимательно читаем. Если бы у вас была связь многие-ко многим. Т.е.
>к примеру на один лицевой счет можно привязать пачку услуг. И
>к нескольким лицевым счетам разные услуги... проблем бы вообще не возникало.

эээ может просто при генерации счетов сделать групировку разходов?
я всеравно не понимаю если контракт заключен с одной компанией и деньги поступают от нее то какой смысл держать несколько лицевых счетов для нее(в рамках одного контракта)?

Пожалуйста приведите живой пример, имена и фамилии замените :)


Ответить | Правка | Наверх | Cообщить модератору

47. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 23-Июл-04, 14:08 
>эээ может просто при генерации счетов сделать групировку разходов?
>я всеравно не понимаю если контракт заключен с одной компанией и деньги
>поступают от нее то какой смысл держать несколько лицевых счетов для
>нее(в рамках одного контракта)?
>
>Пожалуйста приведите живой пример, имена и фамилии замените :)

Клиент А имеет 3 компьютера. Все они подключены к сети. Работают по предаплате. На комп А1 оплочено 50Мб , на комп А2 60Мб, на комп А3 120Мб и еще подключеная услуга ip-телефонии. Разрулите без 3 лицевых счетов. Чтобы деньги снимались правильно. Плюс может быть несколько филиалов одной фирмы в одном городе. На фирму заведен контракт, а на каждый из филиалов по лицевому счету. Еще или хватит?

Ответить | Правка | Наверх | Cообщить модератору

51. "Структура открытой системы биллинга"  +/
Сообщение от garaemail (??), 23-Июл-04, 14:46 

>>Пожалуйста приведите живой пример, имена и фамилии замените :)
>
>Клиент А имеет 3 компьютера. Все они подключены к сети. Работают по
>предаплате. На комп А1 оплочено 50Мб , на комп А2 60Мб,
>на комп А3 120Мб и еще подключеная услуга ip-телефонии.
ЛЕГКО!!!
Услуга такого типа "трафик с включенными МБ + цена за превышение" - т.е. на данный тип определенная логика обработки.
далее. по этому типу создаем 3 услуги. первая включает 50Мб. вторая 60, а третья 120 Мб.  Далее. в контракт добавляем 3 такие услуги. и к каждой услуге привязываем свой IP адрес!!! вот и все и деньги списываются у каждой услуги по своему IP!

ЭТА схема у меня работате 3 ГОДА!!!

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

Решение:
На каждый филиал свой контракт!!!

>Еще или хватит?
ЕЩЕ!!!


Ответить | Правка | Наверх | Cообщить модератору

54. "Структура открытой системы биллинга"  +/
Сообщение от Алексей (??), 23-Июл-04, 15:02 

>>Плюс может быть несколько филиалов одной фирмы в одном городе. На фирму заведен контракт, а на каждый из филиалов по лицевому счету.
>
>Решение:
>На каждый филиал свой контракт!!!
>

И приходим к схеме когда за колбасу платим по одной
кредитке а за сыр другой

Ответить | Правка | Наверх | Cообщить модератору

58. "Структура открытой системы биллинга"  +/
Сообщение от Алексей (??), 23-Июл-04, 15:19 
>>Еще или хватит?
>ЕЩЕ!!!

В тоже схеме клиен А, говорит "Меня не парит сколько мегабайт
превышения сделает комп А1, меня волнует только то чтобы
он не истратил больше Nкилорублей или не больше 3ти денег
на общем счете компании"

Вот в таком варианте счет услуги очень сильно облегчает жизнь

Еще пример. Компания для своих сотрудников хочет купить N pin'ов
для осуществления pre-paid VoIP звонков. При этом требуется, чтобы
только 2 из набора pin'a(гендиректор и его любовница) могли полностью
опустошить счет компании и влезбть в кредит. Еще 10ть пинов всегда имели
бюджет в 25доларов/месяц.
При гибкой тарификации и наворотами типа "любимый номер" в минутах
выразиш сколько на какой карточке единиц и всеравно прийдется лезьть в деньги

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

69. "Структура открытой системы биллинга"  +/
Сообщение от norguhtaremail (?), 25-Июл-04, 04:02 

>ЛЕГКО!!!
>Услуга такого типа "трафик с включенными МБ + цена за превышение" -
>т.е. на данный тип определенная логика обработки.
>далее. по этому типу создаем 3 услуги. первая включает 50Мб. вторая 60,
>а третья 120 Мб.  Далее. в контракт добавляем 3 такие
>услуги. и к каждой услуге привязываем свой IP адрес!!! вот и
>все и деньги списываются у каждой услуги по своему IP!
>
>ЭТА схема у меня работате 3 ГОДА!!!
Стоп! Услуга это услуга... Это на пример услуга предаставления интернета по определенному тарифу. А то мы твои услуги мы будем плодить как кроликов, а это нафиг не надо. Т.е. Услуга это предаставление LAN и WAN с определенными тарифами или IP-телефония к примеру. А уже эти услуги привязываются к лицевым счетам. Проще говоря у нас тут нестыковка в терминах. А так теже яйца только в профиль.
>>Плюс может быть несколько филиалов одной фирмы в одном городе. На фирму заведен контракт, а на каждый из филиалов по лицевому счету
>
>Решение:
>На каждый филиал свой контракт!!!
Эээ нафига? И что директору который хочет посмотреть как расходуются деньги в каждом из филиалов иметь на руках 3 пароля на статистику? В высшей степени маразм. Представьте, что вы уже заключили договор. Открыли филиал пришли... а вам говорят: А! У вас новый филиал? И вы хотите чтобы считалось отдельно? А давайте еще заведем контракт ? Любой нормальный человек спросит: А ЗАЧЕМ ??? И будет прав. А если у него этих филиалов 20 в городе? И он вдруг решит глобально перейти на другого провайдера? Это прийдется закрывать 20 контрактов... С такой системой крупные клиенты вас пошлют и будут правы.

>ЕЩЕ!!! Сколько угодно. Читаем откоменнтированное.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

10. "Структура открытой системы биллинга"  +/
Сообщение от Dmitryemail (??), 22-Июл-04, 08:22 
>Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если
>надо учитывает разные параметры и говорит билингу сколько надо списать. А
>за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно.

Когда вытсавляешь счет, лучше детализировать за какую услугу сколько платят.
Распечатка звонков, тот или иной трафик, итд итп.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

11. "Структура открытой системы биллинга"  +/
Сообщение от gara (??), 22-Июл-04, 10:02 
>>Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если
>>надо учитывает разные параметры и говорит билингу сколько надо списать. А
>>за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно.
>
>Когда вытсавляешь счет, лучше детализировать за какую услугу сколько платят.
>Распечатка звонков, тот или иной трафик, итд итп.

Естественно. Только это должно быть реализованно не в ядре билинга в модуль-услуге. А в модуль-услугу можно напихать любую детализацию.

Ответить | Правка | Наверх | Cообщить модератору

5. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 21-Июл-04, 16:58 
>Кроме этого  возможна реализация модулей НЕУСЛУГ.
>
>Например:
>  - Пополнение счета с помощью различных платежных карт.
>  - Экспорт данных в бухгалтерские программы и Execel.
>  - Статистические, финансовые  и аналитические отчеты.
>  - и т.д.

сие скажем так сервисные вещи к Биллингу относится мало.

>Такая модульность позволяет менять "поведение" билинга, в зависимости от
>того какие модули и/или модуль - услуги подключены.
Модульность и гибкость структуры ограничена структурой базы СУБД.
Эээ а где все тоже, но в виде ER диаграммы. Плюс если не хочется гемороя MySQL как поддерживаемая СУБД присутвовать не должена. Поскольку эта СУБД не позволяет реализовывать хранимые процедуры. Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто. Чего хочется. Более подробного описания алгоритма, ER-диаграммы в 3 нормальной форме ;).

>Неотъемлемой частью билинга есть возможность пользователя управлять >контрактом.
>Подразумевает наличие интерфейса пользователя к своему контракту.
>Возможность вносить какие-то изменения. Например блокировать "элемент
>услуги". Отказываться от услуги. Менять услугу с одной на другую.
>"Покупать" услугу.
По SSL и пароль без причин менять нельзя. Еще лучше по ЭЦП чтоб заход был :) (по SSL сертификатам). По минимуму просмотр статистики. По максимуму добавление услуг.

По первому типу услуг ip-телефония dial-up карточки. Ноги должны расти от RADIUS. И мое ИМХО лучше использовать FreeRADIUS как бы не вопили из GPL радиусов. Это лучшее.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

6. "Структура открытой системы биллинга"  +/
Сообщение от garaemail (??), 21-Июл-04, 18:46 
>Модульность и гибкость структуры ограничена структурой базы СУБД.
>Эээ а где все тоже, но в виде ER диаграммы. Плюс если
>не хочется гемороя MySQL как поддерживаемая СУБД присутвовать не должена.
>Поскольку эта СУБД не позволяет реализовывать хранимые процедуры.
Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно подвесить базу.

>Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто.
Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок.


>Чего хочется. Более подробного описания алгоритма, ER-диаграммы в 3 нормальной форме ;).

более подробный алгоритм будет позже. Кстати можете присоедениться к его описанию...

>
>По первому типу услуг ip-телефония dial-up карточки. Ноги должны расти от RADIUS.

Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и поделиться с юлижним) модуль имеющий те или инные возможности и соответствующие интерфейсы.

Ответить | Правка | Наверх | Cообщить модератору

9. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 22-Июл-04, 07:23 
>Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно
>подвесить базу.
Нефиг зацикливаться. Правильно написанные процедуры работают быстрее внешних программных модулей в биллинге. Плюс перенос и модификация хранимых процедур проще чем перенос и модификация внешних программных модулей.

>>Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто.
>Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок.
См. как сделана реализация модулей SQL во FreeRADIUS. Все четко и легко меняется. И практически не зависит от СУБД

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

>Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и >поделиться с  ближним) модуль имеющий те или инные возможности и >соответствующие интерфейсы.
Не совсем понятно. Единый будет продукт или солянка из пачки билингов ?
RADIUS собственно предназначен именно для авторизации и акакунтинга dialup в дальнейшем его возможности хорошо подошли к VPN и VoIP. Реализация самой процедуры сбора проста. Проблема только это все потом обработать :)


Ответить | Правка | Наверх | Cообщить модератору

13. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 22-Июл-04, 10:15 
>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.

Ответить | Правка | Наверх | Cообщить модератору

14. "Структура открытой системы биллинга"  +/
Сообщение от gara (??), 22-Июл-04, 10:21 
>>Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно
>>подвесить базу.
>Нефиг зацикливаться. Правильно написанные процедуры работают быстрее внешних программных модулей в биллинге.
>Плюс перенос и модификация хранимых процедур проще чем перенос и модификация
>внешних программных модулей.
Это еще как сказать...
Если изначально писать под MySQL то работать будет на любой СУБД.
А если использовать хранимые процедуры то чтоб перенести придется переписывать весь синтаксис. Алгоритм да останется, но синтаксис ой как будет отличаться....

>
>>>Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто.
>>Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок.
>См. как сделана реализация модулей SQL во FreeRADIUS. Все четко и легко
>меняется. И практически не зависит от СУБД
Несомневаюсь что все легко потомучто sql запросы сделаны универсальными, даже упращенными - для mysql (потому как ИМХО проще некуда).

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

Буду рад.
На днях откроется сайт под это дело и там можно будет это дело выкладывать - обсуждать.

>>Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и >поделиться с  ближним) модуль имеющий те или инные возможности и >соответствующие интерфейсы.
>Не совсем понятно. Единый будет продукт или солянка из пачки билингов ?
>
Единым будет ядро, + солянка модуль-услуг, и доп модулей.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

15. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 22-Июл-04, 15:42 
>>Плюс перенос и модификация хранимых процедур проще чем перенос и модификация
>>внешних программных модулей.
>Это еще как сказать...
>Если изначально писать под MySQL то работать будет на любой СУБД.
Спасибо MySQL даже не вчерашний а позавчерашний день он соответсвует спецификации SQL89,в нем нет хранимых процедур. Равняться на нее в связи с тем что она проста для освоения и переноса не стоит, если в проекте по умлчанию используется MySQL или поддерживается я не буду даже рассматривать этот проект. Поверь гараздо проще изменить логику работы SQL процедуры чем лопатить код внешних процедур на C или C++. Это может сделать и субд деволпер причем так как что изменит всю логику работы процедуры. Сколько раз можно повторять вся бизнес логика должна быть внутри базы, а не снаружи.

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

18. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 22-Июл-04, 16:58 
>работы процедуры. Сколько раз можно повторять вся бизнес логика должна быть
>внутри базы, а не снаружи.
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.
Ответить | Правка | Наверх | Cообщить модератору

21. "Структура открытой системы биллинга"  +/
Сообщение от garaemail (??), 22-Июл-04, 17:30 
>>работы процедуры. Сколько раз можно повторять вся бизнес логика должна быть
>>внутри базы, а не снаружи.
>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.
>

Пишите по русски латиницей плиз, если русских клавишь нету:) не все владеют английским в совершенстве.

Ответить | Правка | Наверх | Cообщить модератору

25. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 22-Июл-04, 19:11 
>Пишите по русски латиницей плиз, если русских клавишь нету:) не все владеют
>английским в совершенстве.
Sorry, I can't. I remember all russian keys position, I just don't have russian keymap. yet. It's temporary.
I'm working in 'billing software' several last years. Almost VoIP billing, as a most complicated case of billing for ISP.
And I'm glad to read the article and the thread :)


Ответить | Правка | Наверх | Cообщить модератору

28. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 23-Июл-04, 07:11 
>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.

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


Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

37. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 23-Июл-04, 11:37 
>Можно делать как угодно. Но трудоемкость изменения и сложности переноса внешних процедур
>на С и их скорость работы по сравнению с сохраненными процедурами
>желает лучшего.
Sorry, but it's wrong.
Pleasey, when you make such statement, ad what database have you in mind.
Because it's for sure wrong for some databases.
Seems your experience with databases is quit restricted.
Ответить | Правка | Наверх | Cообщить модератору

19. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 22-Июл-04, 17:07 
>Ядро любого билинга это БАЗА. Все остальное не важно.
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.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

29. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 23-Июл-04, 07:15 
>>Ядро любого билинга это БАЗА. Все остальное не важно.
>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.


Да для авторизации и храниения инфы о пользователях иногда целесообразно использовать сервера директорий.

Ответить | Правка | Наверх | Cообщить модератору

34. "Структура открытой системы биллинга"  +/
Сообщение от Emiljanemail (?), 23-Июл-04, 10:49 
Exactly right! For instance Oracle Internet Directory.
Ответить | Правка | Наверх | Cообщить модератору

38. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 23-Июл-04, 11:38 
>Да для авторизации и храниения инфы о пользователях иногда целесообразно использовать сервера
>директорий.
It's a common mistake of many people.
Good LDAP server implementation can do MUCH MORE then just authentication and user-info-keeping.
Seems you have a restricted experience with LDAP technology also.
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

48. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 23-Июл-04, 14:11 
>>Да для авторизации и храниения инфы о пользователях иногда целесообразно использовать сервера
>>директорий.
>It's a common mistake of many people.
>Good LDAP server implementation can do MUCH MORE then just authentication and
>user-info-keeping.
>Seems you have a restricted experience with LDAP technology also.


ЭЭЭ например ? :) Я понимаю что в нем можно хранить различную инфомацию. К примеру адресную книгу (да это забивание микроскопом гвоздей). Но как ее еще можно использовать в биллинге?

Ответить | Правка | Наверх | Cообщить модератору

57. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 23-Июл-04, 15:17 

>ЭЭЭ например ? :) Я понимаю что в нем можно хранить различную
>инфомацию. К примеру адресную книгу (да это забивание микроскопом гвоздей). Но
>как ее еще можно использовать в биллинге?
It's exactly what I meant when told about common mistake.
If you hear ldap - it's only about authentication and probably address-book yet :)
Seems you never worked with Directory. At least deep enough.
Directory is nice for tree-based structures, hierarchical structures.
I don't want to convince someone , or to read a lecture here.
Imagine a sellers tree. A hierarchy from managers, sellers, re-sellers, and so on. And each level has own set of customers. And own set of contracts. and so on, and so force.
Sometime the life seems to be hierarchical. Not flat, like a table.
If it works for PeopleSoft, or SAP, why it could not work for 'open billing' ?
Because you never worked with Directory?
Ответить | Правка | Наверх | Cообщить модератору

71. "Структура открытой системы биллинга"  +/
Сообщение от norguhtaremail (?), 25-Июл-04, 04:23 
>It's exactly what I meant when told about common mistake.
>If you hear ldap - it's only about authentication and probably address-book
>yet :)
>Seems you never worked with Directory. At least deep enough.
>Directory is nice for tree-based structures, hierarchical structures.
>I don't want to convince someone , or to read a lecture
>here.
>Imagine a sellers tree. A hierarchy from managers, sellers, re-sellers, and so
>on. And each level has own set of customers. And own
>set of contracts. and so on, and so force.
>Sometime the life seems to be hierarchical. Not flat, like a table.
>
>If it works for PeopleSoft, or SAP, why it could not work
>for 'open billing' ?
>Because you never worked with Directory?


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

Ответить | Правка | Наверх | Cообщить модератору

20. "Структура открытой системы биллинга"  +/
Сообщение от garaemail (??), 22-Июл-04, 17:28 
>>>Плюс перенос и модификация хранимых процедур проще чем перенос и модификация
>>>внешних программных модулей.
>>Это еще как сказать...
>>Если изначально писать под MySQL то работать будет на любой СУБД.
>Спасибо MySQL даже не вчерашний а позавчерашний день он соответсвует спецификации SQL89,в
>нем нет хранимых процедур. Равняться на нее в связи с тем
>что она проста для освоения и переноса не стоит, если в
>проекте по умлчанию используется MySQL или поддерживается я не буду даже
>рассматривать этот проект. Поверь гараздо проще изменить логику работы SQL процедуры
>чем лопатить код внешних процедур на C или C++. Это может
>сделать и субд деволпер причем так как что изменит всю логику
>работы процедуры.
Возможно вы правы.

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

Спорно. Если у нас клиент-сервер то да. Данные хранятся а БД, логика в хранимых процедурах. Клиен - отображает данные и делает запрос на расчет того или иного с помощю хранимых процедур + клиент сам чегото считает. Хранимые процедуры в данном случае сильно экономят трафик.

Если же используется 3_х уровневая архитектура ТО -
1. БД хранит только данные.
2. Сервер "приложений"(в нашем случае скрипты) берет данные из БД  считает, умножает делит и т.д. и результаты записывает в БД.
3. Клиент (броузер или win приложение) работает как терминал - посмотреть, изменить, добавить/удалить и ВСЕ.
Все считают скрипты, на чем они написанны - второе дело.


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


Сегодня накропаю продолжение статиь либо подождем пока запущу сайт.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

30. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 23-Июл-04, 07:40 
>Возможно вы правы.

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

>Спорно. Если у нас клиент-сервер то да. Данные хранятся а БД, логика
>в хранимых процедурах. Клиент - отображает данные и делает запрос на
>расчет того или иного с помощю хранимых процедур + клиент сам
>чегото считает. Хранимые процедуры в данном случае сильно экономят трафик.
В этом и сильная сторона клиент-серверной процедуры. И в идеале клиент ничего не считает. Он только делает запросы. У нас есть сервер он большой пусть считает.

>Если же используется 3_х уровневая архитектура ТО -
>1. БД хранит только данные.
Что такое ТОЛЬКО данные ??? Только таблицы с данными ??? НАФИГА ТОГДА ИСПОЛЬЗОВАТЬ СУБД. Тогда можно юзать berkley db и не париться. Это тоже самое что на танке за земяникой ездить.

>2. Сервер "приложений"(в нашем случае скрипты) берет данные из БД  считает,
>умножает делит и т.д. и результаты записывает в БД.
НАФИГА ???? ЭТО ВСЕ ДОЛЖЕН ДЕЛАТЬ СЕРВЕР СУБД ПРИ ПОМОЩИ В СОХРАНЕННЫХ ПРОЦЕДУР! Кто-то (не я) не знает что и как умеет СУБД сервер класса хотябы FireBird. Дать линк на citforum для просвещения ?

>3. Клиент (броузер или win приложение) работает как терминал - >посмотреть, изменить,
>добавить/удалить и ВСЕ. То что вот место администратора это клиент к СУБД это нормально. А то, что коллекторы не являются ТАКИМИ ЖЕ клиентами к СУБД очень странно... Чем ОНИ отличаются.

>Все считают скрипты, на чем они написанны - второе дело.
ЧТО ОТДАЮТ ДЕЛО ПЕРВОСТЕПЕННОЕ.


Ответить | Правка | Наверх | Cообщить модератору

31. "Структура открытой системы биллинга"  +/
Сообщение от gara (??), 23-Июл-04, 08:59 
>>2. Сервер "приложений"(в нашем случае скрипты) берет данные из БД  считает,
>>умножает делит и т.д. и результаты записывает в БД.
>НАФИГА ???? ЭТО ВСЕ ДОЛЖЕН ДЕЛАТЬ СЕРВЕР СУБД ПРИ ПОМОЩИ В СОХРАНЕННЫХ
>ПРОЦЕДУР! Кто-то (не я) не знает что и как умеет СУБД
>сервер класса хотябы FireBird. Дать линк на citforum для просвещения ?

Я описал ксасическую "3_х уровневую архитектуру" БД-сервер приложений-клиент.
Кричать "я самый умный а вы все ламера" некрасиво.
Также необъективно кричать моя точка зрения самая-самая.
Давайте ссылки, обосновывайте.
У нас идет спор надо юзать хранимые процедуры или нет.
Мои аргументы в пользу того что хранимых процедур ненужно(по крайне мере в ядре):

1. Запросы написанные под MySQL будут работать на любой современной SQL СУБД.

2. Переносимость хранимых процедур - проблема - необходимо переписывать весь синтаксис (самый худший вариант).

3. Хранимые процедуры часто могут вызвать загрузку сервера на 100% что нелопустимо.

И напоследок хочу сказать если наши споры не приведут к результату (т.е. опоненты не согласятся с мнением друг-друга) предлагаю начать с простого.
Делаю все под MySQL(синтаксис запросов), если по ходу хранимые процедуры будут давать неоспоримое преимущество (скорость выполнения, объем кода) будем вводить их.

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

Но все на отдельном сайте,форуме.


Ответить | Правка | Наверх | Cообщить модератору

39. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 23-Июл-04, 11:45 
Definitely Norguhtar has a little knowledge about 3-tier architecture.
But it's a mainstream now. Classic client-server is ina past now.
Look at tpc.org, for example.

Ответить | Правка | Наверх | Cообщить модератору

50. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 23-Июл-04, 14:42 
>Я описал ксасическую "3_х уровневую архитектуру" БД-сервер приложений-клиент.
Которую на данный момент можно викинуть на помойку. Она была хороша когда СУБД уровня MySQL т.е. стандарт SQL 89 года.

>Давайте ссылки, обосновывайте.
Обсновываю. Коллектор делает одну операцию работы с СУБД такой-то ip зашел на такой то ip по такому-то порту, за такой-то промежуток времени прошло столько-то байт. И все.

В вашей. Сначала запрашивает тарифы. Потом по встроенным в него алгоритмам  
подсчитывает сколько денег должен нам клиент за траффик и помещаем в СУБД.

1. 2 раза обращается в СУБД. Кеширование не выход. Когда у вас меняются тарифы вам прийдется принудительно пинать все коллекторы чтобы они взяли новые тарифы.
2. Изменение логики расчета требует изменения клиента. Это очень способствует переносимости.

>1. Запросы написанные под MySQL будут работать на любой современной SQL >СУБД.
Не агрумент. Тогда нет смысла использвать SQL СУБД. С таким же успехом можно пользоваться berkeley db. О чем я уже говорил. У нас на дворе 2004 год. А мы пользуемся версией SQL за 1989 год. И только ради совместимости.
SQL92 четко регламентирует триггеры и хранимые процедуры.

>2. Переносимость хранимых процедур - проблема - необходимо переписывать >весь синтаксис (самый худший вариант).
Ты их писал ??? Хоть одну? Что-то не похоже. Все языки написания хранимых процедур скорее диалекты чем разные языки. И перенести из одной СУБД сравнимой функциональности в другую гараздо проще чем перенос кода с одной ОС в другую или с одной архитектуры на другую.

>3. Хранимые процедуры часто могут вызвать загрузку сервера на 100% что >нелопустимо.
Первое СУБД такой же процесс как и другие и какая загрузка будет это от ОС зависит. Эээ ниразу у меня такого не случалось... Даже при разработке и случайном зацикливании. Может будем писать правильно процедуры?

>И напоследок хочу сказать если наши споры не приведут к результату (т.е.
>опоненты не согласятся с мнением друг-друга) предлагаю начать с простого.
>Делаю все под MySQL(синтаксис запросов).
Тогда извиняйте. Мои наметки для VPN содержат ppp + RADIUS + PostgreSQL
с хранимыми процедурами. Нет смысла начинать с простого. Если сначала хранимые процедуры не внесены в проект, потом не добавить их встанет в написание всего биллинга заново. Реинжиринг только с хранимыми процедурами.

>если по ходу хранимые процедуры будут давать неоспоримое преимущество >(скорость выполнения, объем кода) будем вводить >их.
Как ты это узнаешь если ты их не будешь использовать?

>Но все на отдельном сайте,форуме.
Ждемс.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

55. "Структура открытой системы биллинга"  +/
Сообщение от garaemail (??), 23-Июл-04, 15:03 
>>Я описал ксасическую "3_х уровневую архитектуру" БД-сервер приложений-клиент.
>Которую на данный момент можно викинуть на помойку. Она была хороша когда
>СУБД уровня MySQL т.е. стандарт SQL 89 года.

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


>>Давайте ссылки, обосновывайте.
>Обсновываю. Коллектор делает одну операцию работы с СУБД такой-то ip зашел на
>такой то ip по такому-то порту, за такой-то промежуток времени прошло
>столько-то байт. И все.
>
>В вашей. Сначала запрашивает тарифы. Потом по встроенным в него алгоритмам
>подсчитывает сколько денег должен нам клиент за траффик и помещаем в СУБД.

"Б?^%$# не нервируйте меня" ... где это я моей статье есть слово про трафик или про то как он добавляется или считается. :)))

как будет считать трафик это потом.. погодите... небегите в переди паровоза.

ВСЕ ПРЕДЛАГАЮ ОСТАНОВИТЬСЯ!!!

Ждать отдельного форума и там будем обсуждать каждый вопрос отдельно!


Ответить | Правка | Наверх | Cообщить модератору

62. "Структура открытой системы биллинга"  +/
Сообщение от Norguhtaremail (?), 23-Июл-04, 15:55 
>"Во первых она была разработана гораздо позже чем появились всякие >нормальные БД.
И под очень четкие задачи. Типа форумов и гостевух. Проще говоря для веба.

>Она действительно не во всех случаях хороша.
>Ее надо применять либо когда очень много клиентов конектятся к БД, либо
>когда есть сложные вычисления(в том числе и на базе хранимых процедур),
>которые тормозят всю базу. из-за этого она становится узким местом."
Тогда надо использовать оракл, нормальное железо и нанимать хороших разработчиков. MySQL не панацея. Сложных вычислений типа рядов Фурье в биллинге обычно отсутвуют.

>"Б?^%$# не нервируйте меня" ... где это я моей статье есть слово
>про трафик или про то как он добавляется или считается. :)))
А что тогда имеется в виду под трехуровневой моделью ? Если это не о том что считает ваша пачка скриптов?

>Ждать отдельного форума и там будем обсуждать каждый вопрос отдельно!
Ждемс. Думаю наконец кто-нибудь перестанет упираться и начитать с простого...


Ответить | Правка | Наверх | Cообщить модератору

64. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 23-Июл-04, 16:21 
>>"Во первых она была разработана гораздо позже чем появились всякие >нормальные БД.
>И под очень четкие задачи. Типа форумов и гостевух. Проще говоря для
>веба.
That's wrong again.

And - don't forget the modern software can be modular. "Plug-in-able".
How a plug-in is implemented - as SP/UDF/Trigger/Standalone-module is up to impelentator. and all could be happy :)

Ответить | Правка | Наверх | Cообщить модератору

65. "Структура открытой системы биллинга"  +/
Сообщение от ggv (?), 23-Июл-04, 16:27 
Look at TPC-C
Its task has nothing to do with "Типа форумов и гостевух. Проще говоря для веба."
And now let count - how many solutions are 3-tier based, and how many are classic client/server 2-tier.


Ответить | Правка | Наверх | Cообщить модератору

70. "Структура открытой системы биллинга"  +/
Сообщение от norguhtaremail (?), 25-Июл-04, 04:19 
>
>"Б?^%$# не нервируйте меня" ... где это я моей статье есть слово
>про трафик или про то как он добавляется или считается. :)))
>
Эээ тогда я абслютно не догонаяю нафига нужна просолойка между коллектором и СУБД в классической 3-х уровневой модели. Или оно обеспечивает какой-то не достижимый для меня уровень абстракции?


>как будет считать трафик это потом.. погодите... небегите в переди >паровоза.
>
ЭЭЭ тогда еще раз нафига нужна прослойка между коллектором и СУБД?

Не забываем любой ISP биллинг это СЛОЖНАЯ система. И начинать ее с простого, чтобы во второй версии начать писать заново глупо.

PS: Небольшая мантра от Тома Кайта:

Если можно, сделай это с помощью оператора SQL;
Если это нельзя сделать с помощью одного оператора SQL, сделай это на PL/SQL;
Если это нельзя сделать на PL/SQL, попытайся сделать хранимую процедуру на языке Java;
Если нельзя сделать в Java, сделай это в виде внешней процедуры на языке С;
Если это нельзя реализовывать в виде внешней процедуры на языке C, надо серьезно подумать, зачем это вообще делать...

Кроме этого не воспринимайте СУБД как черный ящик или файл данных с возможносью чтения по индексу.


Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру