1

I'm working on a project that, when all boiled down, is essentially a raffle. The twist is that due to the way we've set the ticket value, a user may be casting 10,000+ tickets.

Essentially, a user can chose to cast a certain number of tickets for any given raffle. At the end of a period of time, a winning ticket is chosen randomly. A users' likelihood of winning is proportional to the number of tickets he/she casts.

My issue is that due to the volume of tickets, storing each ticket individually in the database seems out of the question, but in some way every ticket needs to be accounted for because it will affect the odds.

My fallback option is storing "batches" of tickets per user, assuming that it's rare that a user casts a single ticket at once.

What would be the best and most efficient solution for storing a high volume of tickets in the database?

5
  • 1
    Store the tickets individually. It is not too much data. May 23, 2014 at 19:39
  • To clarify, if a user can cast 10,000+ tickets for one raffle, that's easily tens of millions of tickets overall. If that's not an efficiency issue, I'll gladly accept that answer if you put it below.
    – Ryan
    May 23, 2014 at 19:44
  • This question is more appropriate for dba.stackexchange.com. May 23, 2014 at 19:48
  • Haha okay thanks, I'll take it over there. StackOverflow didn't like this either and they suggested Programmers. Going in circles.
    – Ryan
    May 23, 2014 at 19:51
  • No, as this is fine here as its a conceptual development question. May 23, 2014 at 19:55

1 Answer 1

2

There's no reason to rule out storing the tickets individually. 10's of millions of rows is easily handled by most modern DBMS's. Many, many sites and applications handle data orders of magnitude larger than that. Trying to use a non-normalized work-around would not be more efficient - you'd likely introduce more inefficiencies.

Just make sure you put in the right indexes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.