Hey guys

I have to do a database for a poker site and it requires storing everything.
I notived other places such as party poker have hand numbers and table
numbers and i presume all these come from a database. However they use
logfiles for the actual data of what happened on each hand. As you can
imagine this gets huge very quickly.

So i was trying to decide what is the best way to store this data? Do i:

a) store all hand information and table state information at every point in
the database or

b:)Create log files such as party pokers on the server and have the database
store a location to this log file.

I am thinking option b and then code some form of parser for the log file to
extract data i need for replaying a hand and so on.

Then my table for the hand would be something like:

HandId
TableId
TimeStart
TimeEnd
LogFileLoc

May not even need the timestart time end as this could be in the logfile
too. Of course this would mean i have lots and LOTS of hand logs, i mean ppl
can conceivably play 30-40 hands in one game, and thats a lot of disk IO as
it needs to store every detail at every stage. If someone 'checks' it needs
to be stored so the whole hand can be played back exact.

Its a real challenge and not one i have faced before, does anyone have any
ideas or comments on how best to approach storing data such as this in an
optimal way?

It sounds like you know party poker stores log files (in external files, not
in a database).  I have no idea what they do or how they do it.

Your design would store one log file (text file) per hand.  If you have a
site that is even a little bit popular that would lead to hundreds if not
thousands of files per day.  Yuck.  How do you manage that?  If you are
concerned about file I/O and storing and retrieving files I think that you
just invented a nightmare.

There isn't one right answer.  If you ask 100 people how to proceed you
would probably get 80 different answers.  Is the site live now?  What kind
of activity does it get?  I might start with one [database] table that would
log everything that happened in each poker "table."  You would end up with
one large table really quickly.  That probably does not matter too much
because I don't see why you would need to access the "log" table very often.

If you did need to access the table history often or if you did not want to
deal with one large table you could create one database table per poker
table that you have.  That might begin to complicate things because you
might have to figure out a way to dynamically add new sql tables to store
data happening in the new poker tables.  You would also need to maintain
stored procedures for each of your tables (unless you were going to use
embedded sql and let the application "know" where its data should go.

Or you could go with the one table approach and archive days, weeks, or
months at a time.  You could archive this data to smaller, table (and
possibly time) specific sets of data.  That would allow for easier access.

Show quoteHide quote

sql query - sp
How can I Rearrange my Data
Query taking long-long time
tring’
3 most-recent contact dates