Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
Добрый день, всем! Значит проблема такая: создаётся крупная база справочной системы; в ней будут размещаться клиенты, которые будут оплачивать услуги (список которых будет сформирован, а в дальнеёшем пополняться); для каждого клиента необходимо будет сделать аккаунт; у клиента будет возможность включать/выключать различные услуги (временны'х рамок нет, т.е. он может вкл. услугу на два дня или на 6 месяцев, а также выключать её, когда ему захочется); я так думаю, что проверку аккаунта необходимо проводить каждый день (а то и два раза в день), чтобы узнать, что включено, и если, позволяет баланс, включить это реально. В общем что-то в этом роде должно в конце-концов получиться, может я не всё описал, но примерно так. Кто сможет дать идеи или сайты, где об этом рассказано, большое вам спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2005, 13:49 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
Так можно при активации аккаунта клиентом (в триггере или хранимой процедуре) послать какой-либо alert, если БД это позволяет (IB, Oracle могут точно) и его в БД уже по-человечески обработать. Если alert'ов нет, то можно их эмулировать - писать данные в какую-нибудь таблицу и job-ом каждую минуту ее смотреть, главное понять какой alert и какую смысловую нагрузку он несет. Фишка в том, что если Вы будете смотреть все данные по клиентам, то будет долго, а так в таблице alert'ов их будет мало и быстро, кроме этого, ее можно и чистить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.07.2005, 16:59 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
Подозреваю, что система должна иметь какие-то такие элементы, больше без знания предметной области сказать нечего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 09:20 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
ShtockПодозреваю, что система должна иметь какие-то такие элементы, больше без знания предметной области сказать нечего. Большое тебе спасибо! Вот мой вариант: в таблице AccountsAdditionalServices будет храниться информация о всех организациях и их включенных/выключенных услугах (off_flag = 0 => услуга включена), date = дата когда она включена (включая время), поле amount = количество данной услуги, т.е., например, есть услуга добавление строки для размещения, а если компания захочет разместить более одной строки, то amount*cost_услуги. Все эти данные обновляются дваждый в день. Введена таблица AccountsArchive, в которую всё скидывается после окончания текущего месяца. Но у меня пока такая проблема: возмём 1000 компаний, дополнительные услуги = 15 => таблица AccountsAdditionalServices будет пополняться 1000*15 = 15 000 строк, дважды в день. (15 000*2)*30(дней в месяце) = 900 000 строк за месяц! Не много!? В общем посмотри, может дашь ещё советы!? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 10:09 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
IMHO нормально для любой промышленной СУБД, но, как я уже говорил, можно сделать 2 таблицы: на включение услуги и на выключение.Уменьшите объем записей в каждой таблице раза в 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 11:03 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
А время, в течении которого услуга включена, при расчете стоимости не учитывается? Для чего записывать состояния всех услуг для всех клиентов дважды в день? Можно ввести момент начала-момент окончания данного состояния (флаг и количество). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 11:04 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
To ModelR: А разве именно то, что Вы говорите и не изображено на экране: флаг есть, время есть. Если я правильно понимаю - 2 раза в день одинаковую запись никто и не пишет, если не менялось состояние. Если пишут, то конечно надо паниковать, но по тексту я не нашел.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 11:15 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
ModelRА время, в течении которого услуга включена, при расчете стоимости не учитывается? Для чего записывать состояния всех услуг для всех клиентов дважды в день? Можно ввести момент начала-момент окончания данного состояния (флаг и количество). Спасибо за замечание, но у меня вопрос, как мне определить date_off? С date_on проблем нет, дата включения услуги, а вот date_off, как его опеределять и какое там будет значение во время действия услуги!? Если клиент хочет включить доп.услугу, то if off_flag = 1 then off_flag = 0 and date_on = getdate() and date_off = ? Если клиент хочет выключить услугу, то if off_flag = 0 then off_flag = 1 and date_off = getdate(). Так!? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 11:34 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
ShtockTo ModelR: Если я правильно понимаю - 2 раза в день одинаковую запись никто и не пишет, если не менялось состояние. Написано: (15 000*2)*30(дней в месяце). 2 Автор Для текущего состояния применяется Дата окончания = NULL или максимальная дата, допускаемая СУБД. Назовем это открытым интервалом. Поскольку время при каждом обновлении у вас всегда только возрастает, достаточно найти запись для услуги+клиента с открытым интервалом, и сравнить текущее состояние (флаг и количество) с новым. Если ничего не изменилось, то ничего и не делаем. Иначе закрываем найденный интервал моментом обновления и создаем новый открытый интервал с новым состоянием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 11:47 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
Можно хранить только периоды, когда услуга включена и упразднть флаг. Хотя это сократит объем данных, но может усложнить алгоритмы - периоды выключения и включения теперь при дальнейшем анализе обрабатываются по разному. Если периоды выключения вообще не интересны, то да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 11:54 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
ModelR Поскольку время при каждом обновлении у вас всегда только возрастает, достаточно найти запись для услуги+клиента с открытым интервалом, и сравнить текущее состояние (флаг и количество) с новым. Если ничего не изменилось, то ничего и не делаем. Иначе закрываем найденный интервал моментом обновления и создаем новый открытый интервал с новым состоянием. Не понятно, что значит сравнить текущее состояние с новым и если ничего не изменилось, то ничего не делать. Я думаю, что должно быть так: клиент видит список своих услуг, что-то включено, что-то выключено, затем, он указывает услугу и нажимает на включить. Я беру id этой услуги и ищу по связке услуга-клиент с открытым интервалом и затем выставляю date_off = getdate() для флага = 1, т.е. всё это время услуга была выключена, затем создаю новую запись date_on = getdate(), off_flag = 0 и date_off = NULL, т.е. пошла запись с открытой датой во включенном режиме. (А вы написали, что, если ничего не изменилось, это как!? в любом случае что-то меняем). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 12:05 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
В результате каких-либо проблем или даже штатной работы с клиентов МОГУТ поступить запросы на включение уже включенной услуги или на изменение количества на то же самое количество. На это нужно закладываться на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 12:29 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
извините за 2ОФФ но интересно. Shtock и WYPMAH какими средствами вы рисуете такие схемы ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 12:55 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
Пользователь - клиент. Проект имеет роли. Одна из ролей - "иметь услугу". Область видимости роли - конкретная услуга. Назначение роли на некоторый период. Если пользователю назанчена роль "иметь услугу" на конкретную услугу в настоящее время, то пускаем его к этой услуге. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 12:59 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
ModelRВ результате каких-либо проблем или даже штатной работы с клиентов МОГУТ поступить запросы на включение уже включенной услуги или на изменение количества на то же самое количество. На это нужно закладываться на сервере. Тоже вариант. Кстати, как думаешь, то что я написал от 12:05 является правильным или же нужно ещё думать!? Okramизвините за 2ОФФ но интересно. Shtock и WYPMAH какими средствами вы рисуете такие схемы ? Моя диаграмма сделана в CASE Studio 2.18 от Charonware. В чём рисует Shtock я не знаю. MainFrameПользователь - клиент. Проект имеет роли. Одна из ролей - "иметь услугу". Область видимости роли - конкретная услуга. Назначение роли на некоторый период. Если пользователю назанчена роль "иметь услугу" на конкретную услугу в настоящее время, то пускаем его к этой услуге. А как вести лог по услугам, мне же в конце месяца необходимо будет счет выставить с перечислением всех услуг, которыми пользовался клиент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 13:22 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
WYPMAH А как вести лог по услугам, мне же в конце месяца необходимо будет счет выставить с перечислением всех услуг, которыми пользовался клиент. При следующем назначении не удаляется предыдущее. Т.е. у одного клиента много назанчений одной и той же роли по одной и той же области видимости, но потличаются по периодам. По периодам и начисления. Ну и много областей видимости у одного и того же могут быть естественно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 13:47 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
MainFrameПри следующем назначении не удаляется предыдущее. Т.е. у одного клиента много назанчений одной и той же роли по одной и той же области видимости, но потличаются по периодам. По периодам и начисления. Ну и много областей видимости у одного и того же могут быть естественно. Ваша идея конечно интересна, но всё же не совсем понятно, как работать с ролями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 13:52 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
Я пользуюсь PowerDesigner от Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 14:00 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
Ну роль - это просто число и название + область видимости - т.е. табилца - список услуг. При назанчении пользователям - задаем 1. Роль 2. Конкретную услугу - выбираем из таблицы 3. Период действия - дата начала, дата окончания. Храним назначения в таблице. По ней генерируем таблицу Текущее разрешение - Пользователь, Роли, Область видимости - она всегда на текущий момент - без дат. Таблица генерируется периодически, например, каеждый час, или частями (это вопрос реализации и числа клиентов), А начисления делаем по табилце назначений. А пускаем по табилце разрешений ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 14:05 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
MainFrameНу роль - это просто число и название + область видимости - т.е. табилца - список услуг. При назанчении пользователям - задаем 1. Роль 2. Конкретную услугу - выбираем из таблицы 3. Период действия - дата начала, дата окончания. Храним назначения в таблице. По ней генерируем таблицу Текущее разрешение - Пользователь, Роли, Область видимости - она всегда на текущий момент - без дат. Таблица генерируется периодически, например, каеждый час, или частями (это вопрос реализации и числа клиентов), А начисления делаем по табилце назначений. А пускаем по табилце разрешений Спасибо за разъяснение. В общем, получается тоже самое, что и я реализовал, только название ролей у меня не фигурировало! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 14:07 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
WYPMAH Кстати, как думаешь, то что я написал от 12:05 является правильным или же нужно ещё думать!? Детальней продумать обязательно нужно, но схематично похоже на правду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 17:14 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
WYPMAH MainFrameНу роль - это просто число и название + область видимости - т.е. табилца - список услуг. При назанчении пользователям - задаем 1. Роль 2. Конкретную услугу - выбираем из таблицы 3. Период действия - дата начала, дата окончания. Храним назначения в таблице. По ней генерируем таблицу Текущее разрешение - Пользователь, Роли, Область видимости - она всегда на текущий момент - без дат. Таблица генерируется периодически, например, каеждый час, или частями (это вопрос реализации и числа клиентов), А начисления делаем по табилце назначений. А пускаем по табилце разрешений Спасибо за разъяснение. В общем, получается тоже самое, что и я реализовал, только название ролей у меня не фигурировало! Не совсем однако... . Как я понял WYPMAH предлагает разделить допуск к услуге и фактическое включение/выключение услуги, как в сотовой связи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 17:19 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
Okramкакими средствами вы рисуете такие схемы ? Можно рисовать такое в Dia. Это OpenSource программа на Линухе, но есть порт под винду. Единственно что - под Win2k он постоянно падает. Но под WinXP работает нормально. http://www.gnome.org/projects/dia/ http://dia-installer.sourceforge.net/ http://www.schemamania.org/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.07.2005, 17:33 |
|
||
|
Проектирование системы аккаунтов
|
|||
|---|---|---|---|
|
#18+
ModelRНе совсем однако... . Как я понял WYPMAH предлагает разделить допуск к услуге и фактическое включение/выключение услуги, как в сотовой связи. Почему же я разделяю допуск к услуге и вкл/выключение услуги!? Ведь у меня есть связь [все клиенты]-[все услуги], т.е. у всех клиентов есть все услуги, вот только [off_flag_услуги = 1], т.е. все услуги диактивированы, а вот если уж клиент захочет включить себе услугу и его баланс это позволит, то [off_flag_услуги = 0] и эта услуга влключена у данного клиента. А насчёт сотовой связи ты прав, действительно что-то похожее :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.07.2005, 09:08 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33156481&tid=1545776]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
136ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 270ms |
| total: | 511ms |

| 0 / 0 |
