форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"OpenNews: Структура открытой системы биллинга"

Сообщение от opennews (??) on 21-Июл-04, 15:55

Посетитель под именем gara представил для обсуждения модель открытой системы биллинга. URL: http://www.opennet.me/base/dev/billing_structure.txt.html Новость: http://www.opennet.me/opennews/art.shtml?num=4141

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Структура открытой системы биллинга"

Сообщение от Dmitry (??) on 21-Июл-04, 15:55

1 нет связей по таблица, трудно понять все. Тригерочками кое-что необходимо сделать, например лицевой счет изменять только по приходу/расходу. Нужен email  контактный по пользователю - автомтика рассылать сообщения будет, если уйдет клиент -  можно  продать спамерам ;-). 2 К счету привязываеться пользователь, он может получать услуги,для сего он может заводить отдельные логины (нексолько) и пароли. Управление счетом одно, потребление услуг - другое.

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

	3. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 21-Июл-04, 16:50
	>1 нет связей по таблица, трудно понять все. Тригерочками кое-что необходимо сделать, А до про таблицы и тригерочки пока еще никто не говорил... это просто описание модели. > >2 К счету привязываеться пользователь, он может получать услуги, для сего он может заводить отдельные логины (нексолько) и пароли. А логины и пароли для чего? >Управление счетом одно, потребление услуг - другое. А что такое "счет" в вашем понимании?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Структура открытой системы биллинга"

Сообщение от Dmitry (??) on 21-Июл-04, 15:56

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

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

	4. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 21-Июл-04, 16:52
	> >3 Услуга >3.1 реакция системы на отключения от услуги, тоесть как прекратить потребление пользователем >услуги - скрипт или что-то или ничего. > >3.2 Услугу может быть свободно затребована или выдана администратором ( на всякий >случай напишу) >3.3 Услуга может иметь временную функцию ( тарифы). >3.4 порог отключения по остатку денежных средств или кредит. (спорно на счет >кредита, но корпоративных пользователей за 0 на счету рубить сразу нельзя, >сильно обидятся) > >4. Списание, только временной интервал и все ? Трафик ? Может добавить >три  параметра для учета нескольких параметров.(Тот же трафик внутри AS,РФ >и международный). Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если надо учитывает разные параметры и говорит билингу сколько надо списать. А за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	12. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 22-Июл-04, 10:14
	>Списывать деньги с единого счета (лицевого счета клиента) >порочно. >Ибо клиент потребляющий у Вас разнородные услуги >(например хостинг и диалап) очень часто будет платить за каждую услугу отдельно >(отдельным счетом или отдельной строккой в счете) >соответвенно (при едином счете на все усуги) рано или поздно >встанет вопрос сколько средств со счета можно израсходовать по тому >или другому сервису. Может я неправильно назвал поняти. Обясню по другому - счет клиента это грубо говоря сколько денег у него в билинге(положительных или отрицательных - долги) а при списании денег за услуги ведется список списанных средств - за эту услугу столько, за эту столько. Причем строка списания средств выглядит примерно так: "дата_начала_оказания, дата_окончания_оказания, название услуги(хостинг|трафик|воис|) цена, колво , сумма" >По простому можно под каждую услугу заводить отдельный лицевой счет. >можно же родить "аля" план счетов. >Кроме этого, в биллинге нужно предусмотреть диллеров/реселеров/партнеров А можно поподробнее по этому вопросу? А нельзя диллеров также поместить как _КОНТРАКТ_ ? и прилепить им модуль-услугу реализуюущюю алгоритм для оптовых покупателей. Или сделать еще одни тип контракта: "Диллер", т.е. контракт может быть след типов : "Физ лица", "Юр. лица", "Диллеры","служебные". >Ну и продвинутую подсистему отчетности нужно не забыть. Обязательно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

	26. "Структура открытой системы биллинга"
	Сообщение от uldus (ok) on 22-Июл-04, 22:21
	>p.s. Собрать несколько счетов в один вирутальный проще чем один счет разбить А когда идет предоплата ? Как определите на какой лицевой счет сколько положить, когда в присланной платежке только цена за все услуги в сумме ? >на несколько. Гланое не забыть пользователю дать право переводить >средства с одного своего счета на другой (скажем так с услуги на >услугу) в рамках своего договора. Это как предложить пользователю за колбасу и сыр расплачиваться с разных кредиток. Большинству пользователям как настроят, так и поедет. Кроме как нажимать на несколько кнопок они не умеют. Большинство никогда не полезут что-то куда-то переводить, а в офис ходить по мелочам - проще другого провайдера найти.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

	53. "Структура открытой системы биллинга"
	Сообщение от Алексей (??) on 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) on 23-Июл-04, 22:33
	>3) Общий счет + субсчета + один контракт - клиент платит скопом. >  Вот собственно 3ю схему хранения средств я и пропагандирую. У нас первая схема, но похожая на третью :-) Вместо субсчетов - лимиты по услуге. По такой-то улуге разрешено проработать N часов, потратить M мегобайт и так далее. Для услуг с единовременным списанием стредств (диалап анлимит, хостинг, выделенки с абон. платой), субсчета только запутают все. Детализация дебит/кредит проводится по истории платежей, что позволяет посмотреть состояние "субсчета" за любой период.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 23-Июл-04, 07:00
	>Насколько я помню, нам пришлось отказаться от старого биллинга по причине того, >что много клиентов хотело чтобы деньги списывались за кучу услуг и >логинов с _одного_ счета, т.е. из одного места. Эээ внимательно читаем. Если бы у вас была связь многие-ко многим. Т.е. к примеру на один лицевой счет можно привязать пачку услуг. И к нескольким лицевым счетам разные услуги... проблем бы вообще не возникало. >Бухгалтерия выписывает всегда один счет на контракт, в котором просто расписывается/детализируется список >услуг. И еще дополнительно указывает лицевой счет. Хотя все деньги идут на один контракт. Просто добавляется еще одна связь, а выдавать и так и так легко.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	47. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 23-Июл-04, 14:08
	>эээ может просто при генерации счетов сделать групировку разходов? >я всеравно не понимаю если контракт заключен с одной компанией и деньги >поступают от нее то какой смысл держать несколько лицевых счетов для >нее(в рамках одного контракта)? > >Пожалуйста приведите живой пример, имена и фамилии замените :) Клиент А имеет 3 компьютера. Все они подключены к сети. Работают по предаплате. На комп А1 оплочено 50Мб , на комп А2 60Мб, на комп А3 120Мб и еще подключеная услуга ip-телефонии. Разрулите без 3 лицевых счетов. Чтобы деньги снимались правильно. Плюс может быть несколько филиалов одной фирмы в одном городе. На фирму заведен контракт, а на каждый из филиалов по лицевому счету. Еще или хватит?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 23-Июл-04, 14:46
	>>Пожалуйста приведите живой пример, имена и фамилии замените :) > >Клиент А имеет 3 компьютера. Все они подключены к сети. Работают по >предаплате. На комп А1 оплочено 50Мб , на комп А2 60Мб, >на комп А3 120Мб и еще подключеная услуга ip-телефонии. ЛЕГКО!!! Услуга такого типа "трафик с включенными МБ + цена за превышение" - т.е. на данный тип определенная логика обработки. далее. по этому типу создаем 3 услуги. первая включает 50Мб. вторая 60, а третья 120 Мб.  Далее. в контракт добавляем 3 такие услуги. и к каждой услуге привязываем свой IP адрес!!! вот и все и деньги списываются у каждой услуги по своему IP! ЭТА схема у меня работате 3 ГОДА!!! >Плюс может быть несколько филиалов одной фирмы в одном городе. На фирму заведен контракт, а на каждый из филиалов по лицевому счету. Решение: На каждый филиал свой контракт!!! >Еще или хватит? ЕЩЕ!!!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Структура открытой системы биллинга"
	Сообщение от Алексей (??) on 23-Июл-04, 15:02
	>>Плюс может быть несколько филиалов одной фирмы в одном городе. На фирму заведен контракт, а на каждый из филиалов по лицевому счету. > >Решение: >На каждый филиал свой контракт!!! > И приходим к схеме когда за колбасу платим по одной кредитке а за сыр другой
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Структура открытой системы биллинга"
	Сообщение от Алексей (??) on 23-Июл-04, 15:19
	>>Еще или хватит? >ЕЩЕ!!! В тоже схеме клиен А, говорит "Меня не парит сколько мегабайт превышения сделает комп А1, меня волнует только то чтобы он не истратил больше Nкилорублей или не больше 3ти денег на общем счете компании" Вот в таком варианте счет услуги очень сильно облегчает жизнь Еще пример. Компания для своих сотрудников хочет купить N pin'ов для осуществления pre-paid VoIP звонков. При этом требуется, чтобы только 2 из набора pin'a(гендиректор и его любовница) могли полностью опустошить счет компании и влезбть в кредит. Еще 10ть пинов всегда имели бюджет в 25доларов/месяц. При гибкой тарификации и наворотами типа "любимый номер" в минутах выразиш сколько на какой карточке единиц и всеравно прийдется лезьть в деньги
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	10. "Структура открытой системы биллинга"
	Сообщение от Dmitry (??) on 22-Июл-04, 08:22
	>Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если >надо учитывает разные параметры и говорит билингу сколько надо списать. А >за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно. Когда вытсавляешь счет, лучше детализировать за какую услугу сколько платят. Распечатка звонков, тот или иной трафик, итд итп.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 22-Июл-04, 10:02
	>>Билинг списывает деньги со счета за услуги, а модуль-услуга считает и если >>надо учитывает разные параметры и говорит билингу сколько надо списать. А >>за какие там зоныIP, VoIP или почта-хостинг ядру билинга сильно всеравно. > >Когда вытсавляешь счет, лучше детализировать за какую услугу сколько платят. >Распечатка звонков, тот или иной трафик, итд итп. Естественно. Только это должно быть реализованно не в ядре билинга в модуль-услуге. А в модуль-услугу можно напихать любую детализацию.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 21-Июл-04, 16:58
	>Кроме этого  возможна реализация модулей НЕУСЛУГ. > >Например: >  - Пополнение счета с помощью различных платежных карт. >  - Экспорт данных в бухгалтерские программы и Execel. >  - Статистические, финансовые  и аналитические отчеты. >  - и т.д. сие скажем так сервисные вещи к Биллингу относится мало. >Такая модульность позволяет менять "поведение" билинга, в зависимости от >того какие модули и/или модуль - услуги подключены. Модульность и гибкость структуры ограничена структурой базы СУБД. Эээ а где все тоже, но в виде ER диаграммы. Плюс если не хочется гемороя MySQL как поддерживаемая СУБД присутвовать не должена. Поскольку эта СУБД не позволяет реализовывать хранимые процедуры. Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто. Чего хочется. Более подробного описания алгоритма, ER-диаграммы в 3 нормальной форме ;). >Неотъемлемой частью билинга есть возможность пользователя управлять >контрактом. >Подразумевает наличие интерфейса пользователя к своему контракту. >Возможность вносить какие-то изменения. Например блокировать "элемент >услуги". Отказываться от услуги. Менять услугу с одной на другую. >"Покупать" услугу. По SSL и пароль без причин менять нельзя. Еще лучше по ЭЦП чтоб заход был :) (по SSL сертификатам). По минимуму просмотр статистики. По максимуму добавление услуг. По первому типу услуг ip-телефония dial-up карточки. Ноги должны расти от RADIUS. И мое ИМХО лучше использовать FreeRADIUS как бы не вопили из GPL радиусов. Это лучшее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 21-Июл-04, 18:46
	>Модульность и гибкость структуры ограничена структурой базы СУБД. >Эээ а где все тоже, но в виде ER диаграммы. Плюс если >не хочется гемороя MySQL как поддерживаемая СУБД присутвовать не должена. >Поскольку эта СУБД не позволяет реализовывать хранимые процедуры. Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно подвесить базу. >Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто. Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок. >Чего хочется. Более подробного описания алгоритма, ER-диаграммы в 3 нормальной форме ;). более подробный алгоритм будет позже. Кстати можете присоедениться к его описанию... > >По первому типу услуг ip-телефония dial-up карточки. Ноги должны расти от RADIUS. Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и поделиться с юлижним) модуль имеющий те или инные возможности и соответствующие интерфейсы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 22-Июл-04, 07:23
	>Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно >подвесить базу. Нефиг зацикливаться. Правильно написанные процедуры работают быстрее внешних программных модулей в биллинге. Плюс перенос и модификация хранимых процедур проще чем перенос и модификация внешних программных модулей. >>Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто. >Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок. См. как сделана реализация модулей SQL во FreeRADIUS. Все четко и легко меняется. И практически не зависит от СУБД >более подробный алгоритм будет позже. Кстати можете присоедениться к его описанию... Могу помочь с алгоритмами для первого типа услуг. >Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и >поделиться с  ближним) модуль имеющий те или инные возможности и >соответствующие интерфейсы. Не совсем понятно. Единый будет продукт или солянка из пачки билингов ? RADIUS собственно предназначен именно для авторизации и акакунтинга dialup в дальнейшем его возможности хорошо подошли к VPN и VoIP. Реализация самой процедуры сбора проста. Проблема только это все потом обработать :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Структура открытой системы биллинга"
	Сообщение от ggv on 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 (??) on 22-Июл-04, 10:21
	>>Хранимые процедуры очень полезная весч, НО... неграмотно написанные процедуры погут очень серьезно >>подвесить базу. >Нефиг зацикливаться. Правильно написанные процедуры работают быстрее внешних программных модулей в биллинге. >Плюс перенос и модификация хранимых процедур проще чем перенос и модификация >внешних программных модулей. Это еще как сказать... Если изначально писать под MySQL то работать будет на любой СУБД. А если использовать хранимые процедуры то чтоб перенести придется переписывать весь синтаксис. Алгоритм да останется, но синтаксис ой как будет отличаться.... > >>>Т.о. должно быть PostgreSQL, Firebird и Oracle как дефакто. >>Хочется подумать об универсальности. Что была возможность менять СУБД при увеличении нагрузок. >См. как сделана реализация модулей SQL во FreeRADIUS. Все четко и легко >меняется. И практически не зависит от СУБД Несомневаюсь что все легко потомучто sql запросы сделаны универсальными, даже упращенными - для mysql (потому как ИМХО проще некуда). > >>более подробный алгоритм будет позже. Кстати можете присоедениться к его описанию... >Могу помочь с алгоритмами для первого типа услуг. Буду рад. На днях откроется сайт под это дело и там можно будет это дело выкладывать - обсуждать. >>Реализация модулей-услуг дело каждого. Каждый сам себе может сделать (и >поделиться с  ближним) модуль имеющий те или инные возможности и >соответствующие интерфейсы. >Не совсем понятно. Единый будет продукт или солянка из пачки билингов ? > Единым будет ядро, + солянка модуль-услуг, и доп модулей.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 22-Июл-04, 15:42
	>>Плюс перенос и модификация хранимых процедур проще чем перенос и модификация >>внешних программных модулей. >Это еще как сказать... >Если изначально писать под MySQL то работать будет на любой СУБД. Спасибо MySQL даже не вчерашний а позавчерашний день он соответсвует спецификации SQL89,в нем нет хранимых процедур. Равняться на нее в связи с тем что она проста для освоения и переноса не стоит, если в проекте по умлчанию используется MySQL или поддерживается я не буду даже рассматривать этот проект. Поверь гараздо проще изменить логику работы SQL процедуры чем лопатить код внешних процедур на C или C++. Это может сделать и субд деволпер причем так как что изменит всю логику работы процедуры. Сколько раз можно повторять вся бизнес логика должна быть внутри базы, а не снаружи. >А если использовать хранимые процедуры то чтоб перенести придется >переписывать весь синтаксис. А если переносить внешние процедуры на C на другую *nix платформу или архитектуру мы получим возможные проблемы. При переносе же СУБД с базой содержащей хранимые процедуры на другую платформу или архитектуру это уже проблемы разработчиков СУБД, а не наши. >Алгоритм да останется, но синтаксис ой как будет отличаться.... Главное алгоритм и то что будет на входе и на выходе. А как сильно оно будет отличаться не важно. >Несомневаюсь что все легко потомучто sql запросы сделаны универсальными, >даже упращенными - для mysql (потому как ИМХО проще некуда). Там сделано проще. Там выполняются просто SQL запросы. Т.е. что вы там скормите это на вашей совести. Но все операции accounting конечно ориентированы на insert и update. >На днях откроется сайт под это дело и там можно будет это >дело выкладывать - обсуждать. Ждемс. Поделюсь что умеет ppp + radius ;) >Единым будет ядро, + солянка модуль-услуг, и доп модулей. Что есть ядро ? И модули-услуг и доп. модули? Ядро любого билинга это БАЗА. Все остальное не важно. Пока нет ТЗ и эскиза базы... О ядре говорить рано. Можно лишь наметить какие виды информации будут заноситься о пользователе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Структура открытой системы биллинга"
	Сообщение от ggv on 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. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 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 on 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. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 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. Можно делать как угодно. Но трудоемкость изменения и сложности переноса внешних процедур на С и их скорость работы по сравнению с сохраненными процедурами желает лучшего.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Структура открытой системы биллинга"
	Сообщение от ggv on 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 on 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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 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. "Структура открытой системы биллинга"
	Сообщение от Emiljan on 23-Июл-04, 10:49
	Exactly right! For instance Oracle Internet Directory.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Структура открытой системы биллинга"
	Сообщение от ggv on 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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 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 on 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. "Структура открытой системы биллинга"
	Сообщение от norguhtar on 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. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 22-Июл-04, 17:28
	>>>Плюс перенос и модификация хранимых процедур проще чем перенос и модификация >>>внешних программных модулей. >>Это еще как сказать... >>Если изначально писать под MySQL то работать будет на любой СУБД. >Спасибо MySQL даже не вчерашний а позавчерашний день он соответсвует спецификации SQL89,в >нем нет хранимых процедур. Равняться на нее в связи с тем >что она проста для освоения и переноса не стоит, если в >проекте по умлчанию используется MySQL или поддерживается я не буду даже >рассматривать этот проект. Поверь гараздо проще изменить логику работы SQL процедуры >чем лопатить код внешних процедур на C или C++. Это может >сделать и субд деволпер причем так как что изменит всю логику >работы процедуры. Возможно вы правы. >Сколько раз можно повторять вся бизнес логика должна быть внутри базы, а не снаружи. Спорно. Если у нас клиент-сервер то да. Данные хранятся а БД, логика в хранимых процедурах. Клиен - отображает данные и делает запрос на расчет того или иного с помощю хранимых процедур + клиент сам чегото считает. Хранимые процедуры в данном случае сильно экономят трафик. Если же используется 3_х уровневая архитектура ТО - 1. БД хранит только данные. 2. Сервер "приложений"(в нашем случае скрипты) берет данные из БД  считает, умножает делит и т.д. и результаты записывает в БД. 3. Клиент (броузер или win приложение) работает как терминал - посмотреть, изменить, добавить/удалить и ВСЕ. Все считают скрипты, на чем они написанны - второе дело. >>Единым будет ядро, + солянка модуль-услуг, и доп модулей. >Что есть ядро ? И модули-услуг и доп. модули? >Ядро любого билинга это БАЗА. Все остальное не важно. Сегодня накропаю продолжение статиь либо подождем пока запущу сайт.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 23-Июл-04, 07:40
	>Возможно вы правы. Просто в результате а давайте сделаем СУБД по проще, а кода напишем побольше, нам код понятнее... Возникают трудно модифицируемые и не гибкие приложения. И базу такого приложения использовать часто очень сложно или просто не возможно без повторного написания этого кода. >Спорно. Если у нас клиент-сервер то да. Данные хранятся а БД, логика >в хранимых процедурах. Клиент - отображает данные и делает запрос на >расчет того или иного с помощю хранимых процедур + клиент сам >чегото считает. Хранимые процедуры в данном случае сильно экономят трафик. В этом и сильная сторона клиент-серверной процедуры. И в идеале клиент ничего не считает. Он только делает запросы. У нас есть сервер он большой пусть считает. >Если же используется 3_х уровневая архитектура ТО - >1. БД хранит только данные. Что такое ТОЛЬКО данные ??? Только таблицы с данными ??? НАФИГА ТОГДА ИСПОЛЬЗОВАТЬ СУБД. Тогда можно юзать berkley db и не париться. Это тоже самое что на танке за земяникой ездить. >2. Сервер "приложений"(в нашем случае скрипты) берет данные из БД  считает, >умножает делит и т.д. и результаты записывает в БД. НАФИГА ???? ЭТО ВСЕ ДОЛЖЕН ДЕЛАТЬ СЕРВЕР СУБД ПРИ ПОМОЩИ В СОХРАНЕННЫХ ПРОЦЕДУР! Кто-то (не я) не знает что и как умеет СУБД сервер класса хотябы FireBird. Дать линк на citforum для просвещения ? >3. Клиент (броузер или win приложение) работает как терминал - >посмотреть, изменить, >добавить/удалить и ВСЕ. То что вот место администратора это клиент к СУБД это нормально. А то, что коллекторы не являются ТАКИМИ ЖЕ клиентами к СУБД очень странно... Чем ОНИ отличаются. >Все считают скрипты, на чем они написанны - второе дело. ЧТО ОТДАЮТ ДЕЛО ПЕРВОСТЕПЕННОЕ.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	39. "Структура открытой системы биллинга"
	Сообщение от ggv on 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. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 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 с хранимыми процедурами. Нет смысла начинать с простого. Если сначала хранимые процедуры не внесены в проект, потом не добавить их встанет в написание всего биллинга заново. Реинжиринг только с хранимыми процедурами. >если по ходу хранимые процедуры будут давать неоспоримое преимущество >(скорость выполнения, объем кода) будем вводить >их. Как ты это узнаешь если ты их не будешь использовать? >Но все на отдельном сайте,форуме. Ждемс.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 23-Июл-04, 15:03
	>>Я описал ксасическую "3_х уровневую архитектуру" БД-сервер приложений-клиент. >Которую на данный момент можно викинуть на помойку. Она была хороша когда >СУБД уровня MySQL т.е. стандарт SQL 89 года. "Во первых она была разработана гораздо позже чем появились всякие нормальные БД. Она действительно не во всех случаях хороша. Ее надо применять либо когда очень много клиентов конектятся к БД, либо когда есть сложные вычисления(в том числе и на базе хранимых процедур), которые тормозят всю базу. из-за этого она становится узким местом." >>Давайте ссылки, обосновывайте. >Обсновываю. Коллектор делает одну операцию работы с СУБД такой-то ip зашел на >такой то ip по такому-то порту, за такой-то промежуток времени прошло >столько-то байт. И все. > >В вашей. Сначала запрашивает тарифы. Потом по встроенным в него алгоритмам >подсчитывает сколько денег должен нам клиент за траффик и помещаем в СУБД. "Б?^%$# не нервируйте меня" ... где это я моей статье есть слово про трафик или про то как он добавляется или считается. :))) как будет считать трафик это потом.. погодите... небегите в переди паровоза. ВСЕ ПРЕДЛАГАЮ ОСТАНОВИТЬСЯ!!! Ждать отдельного форума и там будем обсуждать каждый вопрос отдельно!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Структура открытой системы биллинга"
	Сообщение от Norguhtar on 23-Июл-04, 15:55
	>"Во первых она была разработана гораздо позже чем появились всякие >нормальные БД. И под очень четкие задачи. Типа форумов и гостевух. Проще говоря для веба. >Она действительно не во всех случаях хороша. >Ее надо применять либо когда очень много клиентов конектятся к БД, либо >когда есть сложные вычисления(в том числе и на базе хранимых процедур), >которые тормозят всю базу. из-за этого она становится узким местом." Тогда надо использовать оракл, нормальное железо и нанимать хороших разработчиков. MySQL не панацея. Сложных вычислений типа рядов Фурье в биллинге обычно отсутвуют. >"Б?^%$# не нервируйте меня" ... где это я моей статье есть слово >про трафик или про то как он добавляется или считается. :))) А что тогда имеется в виду под трехуровневой моделью ? Если это не о том что считает ваша пачка скриптов? >Ждать отдельного форума и там будем обсуждать каждый вопрос отдельно! Ждемс. Думаю наконец кто-нибудь перестанет упираться и начитать с простого...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Структура открытой системы биллинга"
	Сообщение от ggv on 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 on 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. "Структура открытой системы биллинга"
	Сообщение от norguhtar on 25-Июл-04, 04:19
	> >"Б?^%$# не нервируйте меня" ... где это я моей статье есть слово >про трафик или про то как он добавляется или считается. :))) > Эээ тогда я абслютно не догонаяю нафига нужна просолойка между коллектором и СУБД в классической 3-х уровневой модели. Или оно обеспечивает какой-то не достижимый для меня уровень абстракции? >как будет считать трафик это потом.. погодите... небегите в переди >паровоза. > ЭЭЭ тогда еще раз нафига нужна прослойка между коллектором и СУБД? Не забываем любой ISP биллинг это СЛОЖНАЯ система. И начинать ее с простого, чтобы во второй версии начать писать заново глупо. PS: Небольшая мантра от Тома Кайта: Если можно, сделай это с помощью оператора SQL; Если это нельзя сделать с помощью одного оператора SQL, сделай это на PL/SQL; Если это нельзя сделать на PL/SQL, попытайся сделать хранимую процедуру на языке Java; Если нельзя сделать в Java, сделай это в виде внешней процедуры на языке С; Если это нельзя реализовывать в виде внешней процедуры на языке C, надо серьезно подумать, зачем это вообще делать... Кроме этого не воспринимайте СУБД как черный ящик или файл данных с возможносью чтения по индексу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "Структура открытой системы биллинга"

Сообщение от Jaguar (??) on 22-Июл-04, 18:44

Самое прикольное - то что оплату проще всего интерпретировать как один из сервисов.

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

33. "OpenNews: Структура открытой системы биллинга"

Сообщение от Dmitry (??) on 23-Июл-04, 09:05

Я бы еще предложил ввести таблицу с текущим потребленим и систему отслеживания сеанса потребления. Начало потребления, продолжение потребления ( сравнение потребления с остатком на счету ), конец потребления ( списываем  деньги со счета) 1) Radius может использоваться для регулярных запросов на подтверждение полномочий потребления услуги. Тоесть идет постоянный контроль за наличием денег на счету. 2) Постоянное снятие денег со счета(например раз в минуту) приведет к слишком большому количеству записей, в принципе потом базу можно подчистить, но надо иметь ввиду. 3) таблица будет явно меньше таблицы всех пользователей, много из которых могут быть мертвыми. 4) Мониторинг потребителей. Всегда можно пределать упрощенный сеанс потребления, стар и стоп. Но закрывание услуги по радиусу сразу после опустошения счета крайне необходимо. Плюсом даже не Radius, а например подсчет IP для выделенки тоже лучше делать в реальном времени, а в итоги за день заносить одной записью. Возникает ряд проблем: потребление нескольких сервисов одновременно, перевод денег на счет в момент потребления. Но это не смертельно: суммируешь все потребление по таблице текущего потребления и сравниваешь со счетом, в случае конца потребления можешь все заново пересчитать, можешь перенести запись из текущего потребление. Варианты. Использование храниых процедур - необходимость. Использование БД как тупого хранилища создаст больше проблем.

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

	35. "OpenNews: Структура открытой системы биллинга"
	Сообщение от gara (??) on 23-Июл-04, 11:04
	>Использование храниых процедур - необходимость. В чем выражается эта необходимость... обясните... только подругому а не так как было написанно выше. >Использование БД как тупого хранилища создаст больше проблем. Например?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "OpenNews: Структура открытой системы биллинга"
	Сообщение от Dmitry (??) on 23-Июл-04, 12:09
	>В чем выражается эта необходимость... обясните... только подругому а не так как >было написанно выше. > Самое простое: манипуляция денгами на счете. Пришли деньги, бухгалтер или некий WebMoneyBot должен добавить денег на счет - НЕТ. Он просто должен создать приходную запись, далее деньги на счет падают хранимой процедурой. Тоже самое и с потреблением. НИКАКИХ ПРЯМЯХ ИЗМЕНЕНИЙ состояния счета , только через табицу поступления или/и списывания денег. Все остальное от лукавого. Я писал систему интеграции биллинга ISP с метной система банкоматов, коммуникационную часть. Мне дали только INSERT в одну таблицу, пару раз ткнули носом в ошибки , я поправил код и легко прибил навороченное ранее , добавив компенсирующие записи в туже таблицу с соотвествующими комментаримя . Так что идея не моя, а надежностью и защищенностью такой схемы я остался доволен. Даже если у Вас ( как и у меня) есть трудности в написании хранимой процедуры - это не повод отказаться от такого простого и надежного механизма управления счетом. Я всегда прошу помощи в таких делах, не потому что дурак, а потому что это мне нужно крайне редко. Согласен, не стоит завышать требования к возможностям БД, но и мириться с  серьезными недостатками  какой-либо из них крайне вредно. Увеличение нагрузки - едва ли это вызовет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "OpenNews: Структура открытой системы биллинга"
	Сообщение от gara (??) on 23-Июл-04, 13:17
	>>В чем выражается эта необходимость... обясните... только подругому а не так как >>было написанно выше. >> >Самое простое: манипуляция денгами на счете. >Пришли деньги, бухгалтер или некий WebMoneyBot должен добавить денег на счет - >НЕТ. Он просто должен создать приходную запись, далее деньги на счет >падают хранимой процедурой. Тоже самое и с потреблением. >НИКАКИХ ПРЯМЯХ ИЗМЕНЕНИЙ состояния счета , только через табицу поступления или/и списывания >денег. Все остальное от лукавого. В этом случае использование хранимой процедуры оправдано.согласен. Дальше... еще примеры.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "OpenNews: Структура открытой системы биллинга"
	Сообщение от Dmitry (??) on 23-Июл-04, 15:26
	>В этом случае использование хранимой процедуры оправдано.согласен. >Дальше... еще примеры. Больше примеров нет, чтобы на 100 быть увереным в необходимости. Например прекращение потребления сервиса может происходить и в результате запуска хранимой процедуры + system, это чтобы раз в минуту не пробегать по базе в поисках нулей. Но тут много вариантов обойтись. Надо думать, что и как проще. Может опционально и не похо предусмотреть.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "OpenNews: Структура открытой системы биллинга"
	Сообщение от ggv on 23-Июл-04, 13:23
	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?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "OpenNews: Структура открытой системы биллинга"
	Сообщение от Emiljan on 23-Июл-04, 14:24
	>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?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "OpenNews: Структура открытой системы биллинга"
	Сообщение от ggv on 23-Июл-04, 12:06
	>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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "OpenNews: Структура открытой системы биллинга"
	Сообщение от Dmitry (??) on 23-Июл-04, 12:35
	>>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. Погорячился, с кем не бывает ;-).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "OpenNews: Структура открытой системы биллинга"
	Сообщение от ggv on 23-Июл-04, 13:20
	>Это первое, что лезет в голову, НО проблема в тарифах, зависящих от >времени суток и дня недели. Экстраполировать вперед по времени - слишком >трудно и не красиво. >А если тариф зависит и от времени и от трафика? >А если несколько сервисов кормиться с одного счета? >А если один сервис менее критичен к перебору потребления, другой более. >А если во время потребления услуги был перевод денег, разорвем по старой >  сумме. Извинимся ? итд итп. >Посему отслеживания полномочий потребления должно проходить в реальном времени. These all are correct for post-paid. Sure. Функция предсказывания может >где-то и потребуется, но пока не вижу где. Pre-paid services.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "OpenNews: Структура открытой системы биллинга"
	Сообщение от Dmitry (??) on 23-Июл-04, 15:13
	>These all are correct for post-paid. Sure. post-paid после, или я не правильно понял (может лучше в транслите написать)? Но потребление услуги идет в текущий момент, так что с префиксом post не согласен, Я просто подтверждаю или нет последуещее потребление услуги, до следующего запроса. Такой метод универсальный. Совершенно не нужна экстраполяция по времени,  нужна стоиомсть услуги в текущий момент.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "OpenNews: Структура открытой системы биллинга"
	Сообщение от ggv on 23-Июл-04, 15:25
	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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "OpenNews: Структура открытой системы биллинга"
	Сообщение от Norguhtar on 23-Июл-04, 14:49
	>Это первое, что лезет в голову, НО проблема в тарифах, зависящих от >времени суток и дня недели. Экстраполировать вперед по времени - слишком >трудно и не красиво. Ничего сложного и некрасивого не вижу легко реализуется хранимой процедурой. >А если тариф зависит и от времени и от трафика? Тут да косяк. Не все NAS умеют обращаться еще раз к RADIUS. Учитывайте что RADIUS умеет авторизовать и учитывать. При учете reply не отдаются только при авторизации. >А если во время потребления услуги был перевод денег, разорвем по старой >  сумме. Извинимся ? итд итп. Да тут будет внешная процедура... :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "OpenNews: Структура открытой системы биллинга"
	Сообщение от Dmitry (??) on 23-Июл-04, 15:42
	>>А если тариф зависит и от времени и от трафика? >Тут да косяк. Не все NAS умеют обращаться еще раз к RADIUS. >Учитывайте что RADIUS умеет авторизовать и учитывать. При учете reply не >отдаются только при авторизации. Если  уж так приперло, можно периодически обстукивать по  SNMP устройства и определять трафик или сшибать с NAS пользователя. Но все это кривовато, и опчть же - а позволит ли NAS делать ЭТО. Если нет - на помойку или не выдавать тарифы с трафиком.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "OpenNews: Структура открытой системы биллинга"
	Сообщение от Norguhtar on 23-Июл-04, 15:58
	>>>А если тариф зависит и от времени и от трафика? >>Тут да косяк. Не все NAS умеют обращаться еще раз к RADIUS. >>Учитывайте что RADIUS умеет авторизовать и учитывать. При учете reply не >>отдаются только при авторизации. >Если  уж так приперло, можно периодически обстукивать по  SNMP устройства >и определять трафик или сшибать с NAS пользователя. Но все это >кривовато, и опчть же - а позволит ли NAS делать ЭТО. Либо сделать фиксированную скорость канала ;) Тогда рубить по количеству трафика легко. ;) Нуу а тут много всяких но есть :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "OpenNews: Структура открытой системы биллинга"
	Сообщение от ggv on 23-Июл-04, 18:19
	>Учитывайте что 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
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "OpenNews: Структура открытой системы биллинга"
	Сообщение от gvf on 24-Июл-04, 23:40
	мда-а-а, с интересом прочитал все сообщения.... очень много правильного, НО - возникло ощущение что все участники тянут каждый в свою сторону (имея в виду свои собственные задачи и условия).  Другими словами - нет четкого определения поставленной задачи (т.е. тех. задания). Автор просто описал некую виртуальную структуру (вероятно с целью получше разобраться в предмете, прежде всего для себя...) никакого отношения к реальной жизни не имеющую. вывод: вы сначала ТЗ напишите, а потом уже обсуждайте методы наилучшего решения.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

72. "Структура открытой системы биллинга"

Сообщение от gara (??) on 25-Июл-04, 17:44

ВСЕ!!! ПЕРЕХАЛИ !!! Отписывайтесь пожалуйста только тут: http://openbilling.ru/phorum/

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

	73. "Структура открытой системы биллинга"
	Сообщение от gara (??) on 12-Авг-04, 15:12
	Схематическое представление структуры. http://openbilling.ru/openbilling_struct.jpg
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]