[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]