Очередь+Лог (структура таблицы)

← →
Дмитрий С © (2012-08-08 12:39) [0]

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

Планируемый размер таблицы - несколько миллионов или десятков миллионов записей, сообщений в очереди (ожидающих отправки) до 5000.

← →
Sergey Masloff (2012-08-08 12:41) [1]

Одну таблицу.

← →
Petr V. Abramov © (2012-08-08 12:46) [2]

> Sergey Masloff (08.08.12 12:41) [1]

две :)))

← →
Petr V. Abramov © (2012-08-08 12:49) [3]

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

← →
AV © (2012-08-08 12:49) [4]

3 таблицы :)

t_Messages
ID_MESSAGE
TEXT

t_Logs
ID_LOG
ID_MESSAGE
DATE_TIME
RESULT

t_results
ID_RESULT
TEXT

← →
AV © (2012-08-08 12:54) [5]

> t_Logs
> ID_LOG
> ID_MESSAGE
> DATE_TIME
> ID_RESULT

← →
DVM © (2012-08-08 13:08) [6]

Зачем плодить сущности сверх необходимого? Если единственно действие, которое будет производиться над сообщениями - это их отправка, то вполне достаточно одной таблицы. Если действий множество и необходимо иметь журнал этих действий, то целесообразно иметь 2 таблицы.

← →
Дмитрий С © (2012-08-08 13:13) [7]

> DVM © (08.08.12 13:08) [6]

Действие одно, да. Удобнее, конечно в одной, просто я боюсь перевес отправленных и неотправленных сообщений скажется на производительности сильно.

← →
Медвежонок Пятачок © (2012-08-08 13:18) [8]

перевес отправленных и неотправленных сообщений скажется на производительности сильно.

у тебя там что, кроме флага отправлено\нет ничего больше нету?
даты времени например.....

с чего бы вдруг ей сказаться то сильно?

← →
AV © (2012-08-08 13:19) [9]

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

t_Messages
1 Пошли курить
2 НУ?!

t_results
1 Отправлено
2 Ошибка сети
3 Непонятная ошибка

t_Logs
1 1 [dt1] 2
2 1 [dt2] 1
3 2 [dt3] 1

Сразу видно, что
Первое сообщение пытались отправить 2 раза, первый раз в [dt1] и была ошибка сети. С [dt2] сеть наладилась и все уходило без ошибок.

Пора наехать на админов, почему в [dt1] у них сеть не работала :)

← →
DVM © (2012-08-08 13:27) [10]

> Дмитрий С © (08.08.12 13:13) [7]

> просто я боюсь перевес отправленных и неотправленных сообщений
> скажется на производительности сильно.

субд вообще без разницы выбирать 5000 записей из 1 000 000 или из ста тыщ миллиардов, если есть индексы.

Я в одной аналогичной задаче вообще делал так: так как каждая запись имела ID - первичное ключевое поле, то просто выбирал первые N записей начиная с ID = текущему значению. Текущее значение сохранял в другом месте. И все. Никаких полей не надо. ID записи гарантированно уникальный и всегда возрастает.

← →
Sergey Masloff (2012-08-08 13:36) [12]

DVM © (08.08.12 13:27) [10]
>субд вообще без разницы выбирать 5000 записей из 1 000 000 или из ста >тыщ миллиардов, если есть индексы.
Если индекс с плохой селективностью (как в данном случае) то разница есть.

> Если индекс с плохой селективностью (как в данном случае)
> то разница есть.

если он не bitmap

> Sergey Masloff (08.08.12 13:36) [12]

тут еще дело такое, как часто он будет делать эту выборку и как долго эти данные будут пересылаться, а то ведь может случиться, что время выборки это 1% от времени пересылки, то какая разница тогда, пусть оно даже в 10 раз быстрее будет выбираться - заметно не будет.

← →
Sergey Masloff (2012-08-08 13:43) [15]

> пусть оно даже в 10 раз быстрее будет выбираться - заметно
> не будет.

да тут согласен

Очередь+Лог (структура таблицы) Найти похожие ветки