powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите составить схему данных и схему работы для рассылки уведомлений
11 сообщений из 11, страница 1 из 1
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39025194
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть абоненты, которым оказываются услуги.
Абонентская плата за услуги списывается в начале расчетного периода, расчетный период и его начало у разных абонентов может быть разным.
Есть SQL-запрос, который выбирает тех абонентов, у которых:
1. В настоящий момент услуга подключена.
2. Новый расчетный период наступит в течении 3 суток, точнее < trunc(sysdate)+3 (остаток текущего дня + двое полных суток).
3. На лицевой счете средств недостаточно для списания абонентской платы.
КлиентПериодБалансАбонплатаПлатежИванов07.08.20150300300Петров08.08.20150400400Сидоров08.08.2015200300100
Этим абонентам нужно разослать уведомление о необходимости пополнить лицевой счет.

Список абонентов формируется раз в час.
Этот список отправляется в рассылку, которая занимает какое-то время.
Мне нужно продумать, как этот список отправлять на рассылку, при этом:
- не допустить повторной отправки одного и того же уведомления тому же абоненту;
- обновить информацию для рассылки, если данные изменились, но сообщение еще не было доставлено;
- не пропустить рассылку, если абонент один и тот же, но у него несколько услуг с разным расчетным периодом (например 07.08.2015 подходит к оплате услуга1, а 09.08.2015 подходит к оплате услуга2, в этом случае 05.08.2015 ему уйдет первое уведомление по услуге1, а 07.08.2015 ему уйдет второе уведомление по услуге2);

Не подскажите, где можно почитать, как правильно делать подобные службы рассылок?

________________________
Мы смотрим с оптимизмом...
...в оптический прицел.
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39025201
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alibek B.Список абонентов формируется раз в час.
Нафига, если точность периода - день? Доведи периодичность до одного раза за трое суток и
все проблемы превратятся в фичи. Мне, как абоненту, было бы ништяк, если бы о
необходимости заплатить напоминали периодически, а не разово, поскольку разовое письмо
может потеряться или забыться.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39025226
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovAlibek B.Список абонентов формируется раз в час.
Нафига, если точность периода - день?

Данные (т.е. баланс клиента) может меняться чаще, ТС сказал же.

ТС - вообще вопрос "что делать, если данные в процессе рассылки изменились?" - зависит в первую очередь от того, каким инструментом делается рассылка, и к проектированию СУБД имеет отношение, только в случае если "рассылка" читает курсор по одной записи, что-то там с ней делает и ставит флаг "разослано". А такая постановка вопроса уже подразумевает ответ на Ваш вопрос - Вам нужен обьект "элемент рассылки" с правильным уникальным ключом ( который бы как раз решал Ваши три задачи). Рассылка будет проставлять после обработки флаг для каждого обьекта, Ваша "обработка раз в час" - будет сравнивать свой результат со списком необработанных элементов и вносить изменения, если нужно.
Судя по тому что Вы описали ключ видится как (Клиент, Услуга, Дата списания)
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39025241
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovМне, как абоненту, было бы ништяк, если бы о необходимости заплатить напоминали периодически, а не разово, поскольку разовое письмо может потеряться или забыться.
Для рассылки используется SMS и если не минимизировать количество сообщений, то получается довольно накладно.

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

SMS-сервис, осуществляющий рассылку, можем принимать для рассылки сразу список телефонов с сообщениями.
То есть я отправляю на сервис массив [телефон:текст, телефон:текст, ...] из нескольких сотен или тысяч строк, а он весь этот массив сообщений ставит в очередь на отправку. Так что "курсора" в данном случае нет, я на отправку отправляю сразу весь результат предыдущего SQL-запроса.
Однако сама рассылка сообщений производится не так уж и быстро. И к моменту следующего выполнения SQL-запроса может случиться так, что какие-то сообщения еще не были отправлены. И в этом случае было бы неплохо отменить еще не доставленные сообщения, а вместо них отправить обновленные сообщения, с более актуальной информацией.
На самом SMS-сервисе отменить сообщения и отправить новые я смогу без проблем. Но мне бы понять умозрительно, в форме алгоритма, как это должно осуществляться. Пока что у меня в голове нет видения полного цикла этих процессов, поэтому хотелось бы ознакомиться с советами или существующими системами. Ведь наверняка я сейчас упускаю какие-то моменты.
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39025268
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alibek B.Для рассылки используется SMS и если не минимизировать количество
сообщений, то получается довольно накладно.
Подключите службу "неограниченные СМС", будет всё равно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39025282
kva6513
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alibek B.На самом SMS-сервисе отменить сообщения и отправить новые я смогу без проблем.

Т.е. есть возможность отслеживать прохождение каждого отдельного сообщения ? Если брать за ключ сообщения его номер телефона, на который оно отправляется.
Если состояние к/л отслеживается - ничего нового в программировании состояний нет. Обычная Protocol State Machine. Применительно к мутонам данной задачи:
1. Заводите таблицу, куда будут складываться отобранные для отправки ключи: (Клиент, Услуга, Дата списания), например, как уже предложили, или что там бедут таким уникальным ключом;
2. Таблица с ключами имеет Foreign Key на таблицу сфоормированных сообщений, в которой первичный ключ - номер телефона;
3. Соответственно при каждом запуске задания по отбору новых ключей для сообщений - исключаете из выборки все, что уже присутствует в таблице из п.1;

Ну а на таблицу из п.2 вешаете собственно состояния и тайм-фреймы протокола. Расписываете сначала - какие состояния есть у сообщения. Тут все зависит от того, как идет общение с шлюзом отправки SMS. Может, например, после формирования сообщений из курсора приходится ждать некоего "планового окна отправки сообщений." Т.е. будут состояния: "Сформировано, ждет отправки оператору", "Отправлено оператору", "Оператор принял сообщение в обработку"... Все по факту - как там идет обмен и какие данные доступны с той стороны. И для каждого состояния назначаете свое предельное время жизни, которое и фиксируете в таблице из п. 2.
Дальше либо все проходит тип-топ, тогда данные из таблиц пп. 1, 2 уносятся в архив и перестают работать фильтрами для последующих задач по формированию. Возможно, при этом действии в исходных данных, откуда формруются сообщения, проставляется watermark: по дату <ДД.ММ.ГГГГ> (или по ключу расчетного периода, старшего в группировке) все услуги обработаны.
Либо происходит тайм-аут и в зависимости от состояния сообщений принимается решение - где что почистить (и где отразить факт отмены обработки), что-бы процесс пошел снова.
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39025296
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alibek B.Dimitry SibiryakovМне, как абоненту, было бы ништяк, если бы о необходимости заплатить напоминали периодически, а не разово, поскольку разовое письмо может потеряться или забыться.
Для рассылки используется SMS и если не минимизировать количество сообщений, то получается довольно накладно.

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

Ok, если нужно отправлять разные уведомления только по услугам с разными днями оплаты - в ключе "услуга" не нужна, оставьте
только (Клиент, ДатаОплаты)


Alibek B.SMS-сервис, осуществляющий рассылку, можем принимать для рассылки сразу список телефонов с сообщениями.
То есть я отправляю на сервис массив [телефон:текст, телефон:текст, ...] из нескольких сотен или тысяч строк, а он весь этот массив сообщений ставит в очередь на отправку. Так что "курсора" в данном случае нет, я на отправку отправляю сразу весь результат предыдущего SQL-запроса.
Однако сама рассылка сообщений производится не так уж и быстро. И к моменту следующего выполнения SQL-запроса может случиться так, что какие-то сообщения еще не были отправлены.
И как Ваша программа сможет понять, что отправлено а что нет?
В том-то и дело - если Вы хотите программно исправлять изменившиеся в процессе отправки данные, Вам надо и прогресс процесса отправки хранить у себя в БД.
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39026575
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что мешает вам "снизить" объем отправляемых сообщений за один раз и увеличить периодичность отправки?
Оставляю за кадром, что в нормальной системе СМС должны обладать признаком "типа сообщения": информационное/уведомление/реклама/срочное/сообщение о балансе и т.п. Принимаем за факт, что далее по тексту рассматриваются только СМС нужного типа клиенту (с уведомлением о балансе).

Каждое СМС должно у вас проходить как минимум следующие стадии/статусы:
1. Новое/только что сформированное.
2. Готовое к отправке на шлюз.
3. Переданное на шлюз.
4. Доставленное клиенту.

Также три асинхронных могут процесса могут решить вашу проблему:
а) постановка СМС в очередь в шлюз на отправку (на этом этапе вы получаете уникальный ИД СМС, который потом можно использовать для отслеживания его статуса). Постановка СМС в очередь осуществляется только для тех аккаунтов/клиентов/договоров, у которых нет сообщений в статусе "переданно на шлюз/готовое к отправке на шлюз" (не путать с доставленными).


б) опрос статуса переданных в шлюз сообщений. Сохранение статуса в базе.


в) замена СМС: если для одного номера/абонентского договора/счета (вообщем идентификатора клиента)
вдруг есть два СМС - одно со статусом "Новое/Не переданное на шлюз/Только что сформированное" а второе "Готовое к отправке на шлюз"/"Переданное на шлюз, но не доставленное абоненту" - провести последовательные действия:
в.1) опрос текущего статуса второго сообщения
в.2) если статус не доставлено - отменить его
в.3) для первого сообщения проставить статус "готово к отправке".
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39026581
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
при правильном проектировании у вас получатся отдельные модули:
а) работа с шлюзом на постановку СМС в очередь
б) работа с шлюзом на получение статуса СМС/взаимодействие с шлюзом по отмене СМС

остальное все можно "спустить" на уровень хранимых процедур базы.
При этом пункт а) может и должен работать не только под эту задачу, но и в целом на отправку СМС (всех СМС в системе).
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39026638
Alibek B
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за советы.
Остановился на следующей схеме (упрощенно).

Таблица MAIL_BATCH
ПолеТипОписаниеbatch_idintИдентификатор заданияtitlevarcharНаименованиеdate_createdateДата создания заданияdate_expiredateСрок актуальности заданияstatevarcharТекущий статус задания

Таблица MAIL_MESSAGE
ПолеТипОписаниеmessage_idintИдентификатор сообщенияbatch_idintЗадание рассылкиclient_idintКлиентkeyvarcharУникальный ключ рассылки (расчетный период)

1. update mail_batch set state='delete' where date_expire<sysdate-7

2. delete from mail_message where batch_id in (select batch_id from mail_batch where state='delete')
.
3. SQL-запрос для получения списка абонентов для рассылки (некоторые проверки нельзя осуществить на сервере СУБД, поэтому список абонентов я забираю на клиента и делаю проверки там).

4. select client_id, key from mail_batch join mail_message using batch_id where state='new' and date_expire>sysdate
Результат запроса помещаю в ассоциативный массив, чтобы быстро проверять наличие существующих записей из пункта 3.

5. Фильтрация списка абонентов для рассылки. Если после фильтрации остались сообщения для рассылки, создание записи в mail_batch (c state='new'), проход по списку в цикле.
Если сообщение для клиента уже есть в списке сформированных сообщений (из пункта 4), то проверить статус сообщения на шлюзе; если оно еще не доставлено, то отменить его и сформировать обновленную версию.
Если сообщение для клиента не было сформировано ранее, то создание записи в mail_message.

6. Отправка сформированных сообщений на SMS-шлюз.


Кот МатроскинИ как Ваша программа сможет понять, что отправлено а что нет?
Запросит статус сообщения на шлюзе. Если статус "Доставлено", значит уже все. Если статус другой, значит еще не доставлено.


Mikle83Каждое СМС должно у вас проходить как минимум следующие стадии/статусы:
Зачем стадии 1-3 разделять? Это одна стадия.
...
Рейтинг: 0 / 0
Помогите составить схему данных и схему работы для рассылки уведомлений
    #39026907
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alibek B.Mikle83Каждое СМС должно у вас проходить как минимум следующие стадии/статусы:
1. Новое/только что сформированное.
2. Готовое к отправке на шлюз.
3. Переданное на шлюз.
4. Доставленное клиенту.
Зачем стадии 1-3 разделять? Это одна стадия.

Как реализуете. В общем случае подготовкой СМС у вас могут заниматься несколько механизмов (отчетность/модули мониторинга/билинговая система/рекламный модуль/СРМ система и т.п.), которые будут "складывать" сообщения в единое хранилище со статусом "НОВОЕ". Каждое СМС будет иметь как минимум приоритет отправки.

Соответственно модуль, занимающийся постановкой СМС в очередь на шлюз, будет выбирать из общего пула "НОВЫХ" сообщений записи в порядке приоритета и маркировать их "Передано на Шлюз" только после соответствующих действий.

Сообщение в статусе "НОВОЕ" может быть отменено без запроса в стороннюю систему.

"Готовое к отправке на шлюз" - предполагается маркировать тот пул, который в текущий момент обрабатывается/передается на отправку, отменять такое сообщение достаточно рисковано - надо видеть ваш протокол обмена со шлюзом. Время постановки СМС в очередь на шлюз может составлять существенную величину (несколько десятков минут).
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите составить схему данных и схему работы для рассылки уведомлений
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]