[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] A crude proposal for a database schema
From: |
Jim Segrave |
Subject: |
Re: [Bug-gnubg] A crude proposal for a database schema |
Date: |
Wed, 3 Sep 2003 20:04:08 +0200 |
User-agent: |
Mutt/1.4.1i |
On Wed 03 Sep 2003 (17:48 +0000), Joern Thyssen wrote:
> On Tue, Sep 02, 2003 at 08:18:24PM +0200, Jim Segrave wrote
[A lot that needs reviewing]
> > Table: Moves ID GameID PlayerID on roll Dice int(2) move int(8),
> > movetype enum (double, pass, drop, take, beaver, raccoon, normal,
> > set position), boardID, isbest (boolean), analysis stats
> > bestmovetype enum (double, pass...), bestmove int(8), analysis
> > stats
>
> I'd say that we "drop" the Moves table for now, since I guess most
> people would want to query game data rather than move data. Also, the
> Moves table is the most complicated one. We'll probably learn a lot
> implementing the other tables, so I think we should leave out the most
> complex one for now.
As long as one keeps in mind that people are going to want it - in
particular to find mistakes.
> > gnubg could write the records out easily (we'd need some method of
> > filling in data like player name to nickname mappings and environments
> > I want to change the GAME_INFO record to have a datestamp (I get
> > annoyed if I play two matches against gnubg and analyse them that
> > gnubg wants to overwrite the first matche's .sgf file).
>
> Using IDs (env, player, match/session) requires us to have direct access
> to the RDBMS so we can query the database for next "free" ID unless we
> find some other way to generate unique IDs.
MySql has auto-generated IDs - very convenient. I don't know about
other RDBs though. I'll ask the local experts tomorrow about
postgres. I believe MSql does not.
--
Jim Segrave address@hidden