Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2013.03.22;
Скачать: CL | DM;

Вниз

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

 
Дмитрий С ©   (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 или из ста тыщ миллиардов, если есть индексы.


 
DVM ©   (2012-08-08 13:30) [11]

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


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

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


 
AV ©   (2012-08-08 13:38) [13]


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

если он не bitmap


 
DVM ©   (2012-08-08 13:40) [14]


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

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


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


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

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



Страницы: 1 вся ветка

Текущий архив: 2013.03.22;
Скачать: CL | DM;

Наверх




Память: 0.5 MB
Время: 0.221 c
2-1341059064
Начинающий41
2012-06-30 16:24
2013.03.22
DBEDIT


2-1342265873
rioko
2012-07-14 15:37
2013.03.22
StringGrid и удаление выделеных строк.


3-1278782038
TechnoDreamer
2010-07-10 21:13
2013.03.22
DBX Error: Unsupported field type


15-1351168672
картман
2012-10-25 16:37
2013.03.22
что за вольный стиль?


4-1259658224
sniknik
2009-12-01 12:03
2013.03.22
Получить список групп текущего юзера/общий