Вопросик по организации БД

[alibek]

Всем привет

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

Это все лирика
Теперь как это лучше реализовать.
Клиенты обслуживаются с помощью моей проги. Есть БД, в которой хранится куча информации (клиенты, их телефоны и пр.). Теперь надо добавить возможность проведения лотерей.

Механизм проведения подобных лотерей давным-давно отработан и над ним мне не пришлось даже задуматься -- создается табличка со всеми возможными играющими комбинациями (числа от 0000 до 9999), у каждого числа есть атрибут или статус (не сыграла, сыграла, выиграла, проиграла), при генерации билета делается выборка чисел в статусе "не сыграла", берется произвольная запись выборки, после чего ее статус меняется на "сыграла". По результатам игры всем записям в статусе "сыграла" присваивается статус "проиграла" кроме той комбинации, которая выиграла. Если игр предполагается несколько, то к таблице добавляется еще поле GAME_ID, которое будет одинаково для всех комбинаций данной игры.

Сложностей две. Во-первых, акции будут проводится довольно регулярно (раз в неделю) и неограниченное время. Т.е. каждую неделю в БД будет добавляться по 10000 записей.
Назначение акции сугубо вспомогательное и рекламное и хранить в основной БД такую справочную информацию как-то неразумно.
Можно конечно после проведения игры удалять все записи в этой таблице и генерировать номера заново, но все-равно база будет раздуваться.

Пока что я пришел к тому, что для этих целей используется вспомогательная БД, в которой храниться вся информация (все сгенерированные комбинации) для всех игр. А в основную БД копируются только выигравшие комбинации (одна запись на игру).

Но может коллективный разум форума подскажет способ лучше?

[codemaster]

тип БД ?

[alibek]

Access
На деле Access только временно, будет MSSQL.

[codemaster]

Посмотри эту статью

думаю то что тебе надо
http://www.rsdn.ru/article/db/RDBMS.xml

[alibek]

Почитал. Помоему это не то.
В данном случае не будет проблемой огромные объемы данных и/или долгое выполнение запросов.
Просто тот алгоритм, который я выбрал, подразумевает большую избыточность хранимой информации. И хотелось бы от этой избыточности уйти.
Одна из идей -- не генерировать все возможные комбинации для каждой игры, а сгенерировать их один раз. А когда потребуется сгенерировать комбинацию для билета, использовать что-то вроде (select num from num_pool minus select num from actions where state=1).

[codemaster]

Просто тот алгоритм, который я выбрал, подразумевает большую избыточность хранимой информации. И хотелось бы от этой избыточности уйти.
.

Как вариант
Сохраняй в БД только выигравшие комбинации.

[alibek]

Только выигравших будет одна на всю игру, и сохранять ее я собираюсь в основной базе. Просто еще следовало бы сохранять информацию по сыгравшим, но не выигравшим.

[codemaster]

Только выигравших будет одна на всю игру, и сохранять ее я собираюсь в основной базе. Просто еще следовало бы сохранять информацию по сыгравшим, но не выигравшим.

Или не сыгравшим т.е. их по идее будет меньше (или нет? )и они точно не выиграли .

[alibek]

Есть два варианта.

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

Второй -- игра длится до тех пор, пока приз не будет разыгран. Т.е. если к концу недели приз не разыгрался, то игра продолжается и номера выдаются из этого же номерного пула. В этом случае число сыгравших и несыгравших комбинаций будет в среднем сопоставимо (а в крайних случаях будут разыграны все комбинации).

Хранить информацию хотелось бы не для "галочки", а для того, чтобы решать вопросы с клиентами. Придет, например, какой-нибудь скандальный товарищ поругаться, а ему скажут, когда он брал билет, какой номер был и почему ничего не выиграл.

[Ennor]

Механизм проведения подобных лотерей давным-давно отработан и над ним мне не пришлось даже задуматься

Прочел внимательно весь топик, но так и не понял - а что именно тебе нужно, в таком случае?

[alibek]

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

[FaKk2]

Как я понял, у тебя постоянное кол-во записей чисел, от 0000 до 9999, так?

В таком случае генерируешь их один раз и сохраняешь скажем в tblGameNumbers.

Потом создаешь таблицу tblGame в которой хранишь WinningNumber.

Таким образом у тебя одна таблица будет константой, вторая будет увеличиваться каждую неделю на одну запись.

Теперь, тебе нужно, хранить инфу о выигранном билете и ID клиента, все это хранишь в tblGame.

При генерации номера можно выбирать рандомально число, и проверять выиграно оно или нет. Конечно у этого метода есть недостаток, теоритически время нахождения валидного номера очень велико. Но на практике, ты же будешь обнулять tblGame ну или слать в архив

ПС, может я чего недопонял, пиши.

[alibek]

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

Access, зараза, не знает, что такое MINUS, пришлось на NOT IN заменить. Это сильно плохо?

[FaKk2]

Честно признаюсь, не в курсе. Не пробовал просто.

Но организацию базы сделал бы так как описал.