Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
16.01.2007, 18:13
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
Посоветуйте какую структуру БД выбрать. Есть определенные тарифные планы по основной услуге (н-р, подсчет интернет-трафика или еще чего-то), в которых учитываются различные параметры (время получения услуги, абонплата итд). Все это хранится в одной таблице Тарифы с полями Идентификатор тарифа, Абонплата, Цена единицы потребленной услуги днем, Цена единицы потребленной услуги ночью... Затем появляется новая услуга, н-р, IPTV или игровые сервера. Для пользования ими есть несколько тарифов со своими параметрами (н-р, первый тариф-абонплата за доступ к просмотру видео или второй тариф-без абонплаты, но n руб за час просмотра). Вопрос, как это реализовать в БД. Дополнить существующую таблицу тарифов данными об доп. услугах или создать новую таблицу для них (и для каждого пользователя выбирать по тариф основной услуги и тарифы по доп услугам, записывая идентификаторы тарифов в отдельные поля)? В первом случае не известно, что ставить для уже подключенных клиентов в поля для доп тарифов и число их увеличится в геометрической прогрессии. Во втором случае придется немного менять логику работы программ рейтинга. Вопрос, как это правильно реализовать и предусмотреть возможность появления новых услуг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.01.2007, 18:46
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
Тарифы - это большой и сложный вопрос. Насколько мне известно, идеальной структуры для тарифов - такой, которая подошла бы хотя бы в 95% случаев случайно выбранных услуг случайно выбранных фирм - никто еще не придумал. В целом подход - вычленить все существенные показатели тарификации. То есть разобрать существующие тарифы и составить таблицу так, чтобы она позволяла описать любой имеющийся тариф и сколь можно надеяться - новые. После чего, когда маркетологи опять чего-нибудь выдумают, садиться и дополнять. Скажу еще раз, задача очень и очень непростая. Скажем, представьте себе реализацию таких условий, как "оплата в рублях зачисляется по курсу <источник> на день, следующий за днем оплаты" или "при более чем 400 минутах международных разговоров в месяц на скидка на локальные звонки 30%". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.01.2007, 21:05
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
softwarerТарифы - это большой и сложный вопрос. Насколько мне известно, идеальной структуры для тарифов - такой, которая подошла бы хотя бы в 95% случаев случайно выбранных услуг случайно выбранных фирм - никто еще не придумал. В целом подход - вычленить все существенные показатели тарификации. То есть разобрать существующие тарифы и составить таблицу так, чтобы она позволяла описать любой имеющийся тариф и сколь можно надеяться - новые. После чего, когда маркетологи опять чего-нибудь выдумают, садиться и дополнять. Скажу еще раз, задача очень и очень непростая. Скажем, представьте себе реализацию таких условий, как "оплата в рублях зачисляется по курсу <источник> на день, следующий за днем оплаты" или "при более чем 400 минутах международных разговоров в месяц на скидка на локальные звонки 30%". При наличии только одной таблицы тарифов с множеством полей необходимо создавать очень много тарифов. Например, есть Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. То есть нужно организовать хранение именно тарифов по доп. услугам. Например, в сотовой связи можно подключить антиАОН и за него будет сниматься абонплата или,н-р, плата за количество срабатываний. Я думаю, они при этом не меняют мне тариф с того, где оба этих параметра были нулями, на кокой-то другой.... Интересует как это реализуется у них. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 10:31
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
Сейчас склоняюсь ко второму варианту... Также пока еще не решил, стоит ли хранить детализацию списания денег со счета списания производятся каждый час по триггеру на вставку в соответствующие таблицы (н-р, Код: plaintext 1. 2. 3. 4. 5. 6. 7. PS: может есть у кого-нить ссылка на теорию по этим вопросам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 10:50
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
у казанных примерах не видно полей где описан диапазон действия тарифа имхо надо, хотя бы для примерного пересчета при возхможном переходе на новый тариф ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 11:38
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
Должна быть одна таблица с тарифными планами. К ней одна таблица с самими тарифами, где будут указаны сроки действия, абонплата и т.д. И тип тарифа - чтобы можно было делать что-то специфическое. Хотя тип можно и в планы запихать. И от тарифов таблица с тарифной сеткой - ну не жесткий же тариф, от суммы/объема может варьироваться, тут это и надо учесть. ====== У нас структура удовлетворяет 90% тарифам на почтовые пересылки всеми возможыми операторами и службами. Единственное - Почта России, вот у них не тарифы, а @#$%^&, да и сами они это слово :) -- Tygra's -- Мои фотогалереи тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 12:10
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
tygraДолжна быть одна таблица с тарифными планами. К ней одна таблица с самими тарифами, где будут указаны сроки действия, абонплата и т.д. И тип тарифа - чтобы можно было делать что-то специфическое. Хотя тип можно и в планы запихать. И от тарифов таблица с тарифной сеткой - ну не жесткий же тариф, от суммы/объема может варьироваться, тут это и надо учесть. ====== У нас структура удовлетворяет 90% тарифам на почтовые пересылки всеми возможыми операторами и службами. Единственное - Почта России, вот у них не тарифы, а @#$%^&, да и сами они это слово :) -- Tygra's -- Мои фотогалереи тут Не совсем понял. Можете привести структуру таблиц? Таблица с тарифными планами это как я понял эта таблица Код: plaintext 1. 2. 3. 4. 5. 6. Еще есть таблица Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. Что должно храниться в таблица с тарифными планами, только название и идентификатор тарифа, если все описания в др. таблицах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 13:09
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
Код: plaintext 1. Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. -- Tygra's -- Мои фотогалереи тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 14:56
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
tygraДолжна быть одна таблица с тарифными планами. К ней одна таблица с самими тарифами, где будут указаны сроки действия, абонплата и т.д. Связать эти таблицы через уникальный идентификатор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 15:04
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
postuserТо есть нужно организовать хранение именно тарифов по доп. услугам. Например, в сотовой связи можно подключить антиАОН и за него будет сниматься абонплата Да, конечно, я не очень удачно сформулировал, использовать одну таблицу совершенно не обязательно и почти наверняка вредно. Пляшем мы от услуг (например, тот же антиАОН), на каждую услугу свой тариф или альтернативные тарифы. Тарифные планы - группируют услуги и тарифы, там есть свои тонкости, например при присвоении тарифного плана какие-то услуги считаются заведомо выбранными, какие-то подключаются дополнительно и опционально. Часто пользователь может отдельно заказывать услуги, не входящие в общий тарифный план; бывает, что услуга входит в один тарифный, не входит в другой, но может быть подключена к нему дополнительно. Бывает, что услуга не может быть подключена при данном выбранном тарифном плане. Итп. Реально "тарификация в достаточно общем виде" - это отдельный модуль, большой и сложный. Да еще вдобавок критически важный и зачастую с требованием риалтаймовости - когда нужно, например, отключать предоставление услуги сразу по исчерпании баланса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 16:00
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
какие то проблемы явно с бизнес-анализом Почему бы не провести анализ выделить объекты и связи между ними? Тогда и не будет проблем с тем какие таблицы и сколько их должно быть и как между собой их связать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 17:54
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
softwarer postuserТо есть нужно организовать хранение именно тарифов по доп. услугам. Например, в сотовой связи можно подключить антиАОН и за него будет сниматься абонплата Да, конечно, я не очень удачно сформулировал, использовать одну таблицу совершенно не обязательно и почти наверняка вредно. Пляшем мы от услуг (например, тот же антиАОН), на каждую услугу свой тариф или альтернативные тарифы. Тарифные планы - группируют услуги и тарифы, там есть свои тонкости, например при присвоении тарифного плана какие-то услуги считаются заведомо выбранными, какие-то подключаются дополнительно и опционально. Часто пользователь может отдельно заказывать услуги, не входящие в общий тарифный план; бывает, что услуга входит в один тарифный, не входит в другой, но может быть подключена к нему дополнительно. Бывает, что услуга не может быть подключена при данном выбранном тарифном плане. Итп. Реально "тарификация в достаточно общем виде" - это отдельный модуль, большой и сложный. Да еще вдобавок критически важный и зачастую с требованием риалтаймовости - когда нужно, например, отключать предоставление услуги сразу по исчерпании баланса. Именно это я и имел ввиду. Что есть тарифный план, группирующий услуги и есть услуги, которые не входят в тарифный план, но могут быть подключены. velfimovкакие то проблемы явно с бизнес-анализом Почему бы не провести анализ выделить объекты и связи между ними? Тогда и не будет проблем с тем какие таблицы и сколько их должно быть и как между собой их связать Попробую подробнее описать, что нужно. Есть тарифные планы с предоплатой и есть кредитные тарифные планы (которые со скидками в зависимости от наработанных Мб в месяц). Допустим есть тарифы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Трафик (101-200,...,>1000) Время Абонплата Цена Мб игрового трафика Абонплата игрового трафика Возможно, что отдел маркетинга введет ночные скидки на игровом, тарифицировать будут и вх и исх трафик и некоторые др. параметры. Кроме этого еще нужно хранить стоимость перехода с одного тарифного плана на другой, стоимость подключения услуги (возможно с привязкой к тарифу, например, переход на Стандартный стоит 20 руб, переход на Выгодный 30 руб). И самое главное предусмотреть подключение новых услуг, которых изначально нет в тарифном плане. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.01.2007, 20:34
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
Видел у других и сам дела так. Создал таблицу крассификации данных вида (атрибут, критерий, порог, индекс, предок). PK(предок, порог). Атрибут - имя атрибута услуги, который требуется классифицировать. Критерий - индекс метода сравнения фактического значения атрибута услуги со значениями порогов в подчинённых записях. Метод возвращает значение поля индекс подходящей записи среди прямых потомков текущей записи. Порог - пороговое значение атрибута для которого действует данный индекс. Индекс - класс значений атрибута. Предок - ссылка на родительскую запись. Как это работает. Находим в классификаторе корневую запись, которая не имеет предка. Читаем имя атрибута из корневой записи и получаем его значение из CDR. Применяем критерий. Метод критерия ищет среди прямых потомков подходящую запись, сохраняет её индекс в вектор и делает её текущей корневой записью и переходит к п.2. В итоге получаем вектор индексов. Создал таблицу тарифов. (значение индекса 1, ... значение индекса 10, формула, параметр1, ..., параметр10). PK (значение индекса 1, ... значение индекса 10). Используя полученный на этапе классификации вектор индексов нахожу запись в таблице тарифов. В формулу передаю CDR и векрор параметров (параметр1, ..., параметр10). На выходе получаю цену и прочие результаты. Т.е. сначала выполняем иерархическую классификацию данных услуги (по диапазонам значений), затем матричную (по индексам) и аналитическую (набор встроенных готовых и пользовательских процедур). Полагаю, удобнее иметь возможность чередования этих видов классификации но такую реализацию не видел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.01.2007, 08:30
|
|||
|---|---|---|---|
Принципы хранения тарифов в БД |
|||
|
#18+
tygraНу и для гибкой тарификации в зависимости от объема -это тарифная сетка. Скорее всего, буду реализовывать ваш вариант. Еще интересуют алгоритмы расчета по тарифной сетке. Это только для кредитных планов можно реализовать или для предоплатных тоже? Ведь в тарифе имеется наработка за месяц (расчетный период) при превышении которой будет считаться по более низкой цене, а в течении месяца это предусмотреть невозможно. Есть вариант каждый раз при скидывании данных в базу суммировать трафик по текущий день и пересчитывать суммы оплаты, но это сильно нагрузит базу (агрегирование по каждому клиенту за месяц). Поэтому думаю, это только для кредитных планов. И вопрос с подключаемыми услугами, которых изначально нет в тарифном плане (у кого-то они могут быть включенными, у кого-то на этом же тарифе может их не быть, н-р, игровой сервер, потоковое видео итд, а создание отдельных планов, учитывающих все это приведет к сильному разрастанию их кол-ва) остается открытым... Пока в голову ничего не приходит как создание для них отдельных таблиц такой же структуры как и для основных тарифов и хранения в таблице клиентов сразу нескольких тарифных планов: Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=32&mobile=1&tid=1544787]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
164ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 494ms |
| 0 / 0 |
