Re: [Bug-gnubg] Match statistics graph

[Joern Thyssen]

On Fri, Aug 29, 2003 at 05:47:16PM +0200, Jim Segrave wrote
> 
> I think this is the big divide between the Unix background and the
> Windows background, Unix has the idea of lots of generic tools as
> separate pieces which get assembled to meet requirements, Windows has
> the idea (even if it's by sharing IE as the basic rendering platform),
> of monolithic do-all tools.

Yes, that's a good point.

> But most of what Albert mentions are actually derivations from simple
> game data. Assume that gnubg can output a CSV file for every game
> played containing:
> 
> date & time (I'd also suggest putting in the Unix time() value, as
>              it's much easier to process)
> player names
> type - match/money game
> score
> rules/context - jacoby, crawford, post-crawford
> result
> luck total/average
> chequer/cube/overall total and average errors
> moves forced/total
> 
> This can be imported into almost every existing database or
> spreadsheet, from which all of the data mentioned here can be
> reasonably easily extracted and displayed in bar/line/point graphs,
> pie charts, 3d surfaces, etc. Users can either let the CSV file
> accumulate or periodically import it into a more flexible database and
> delete the current one. Then they can use real data manipulation tools
> rather than ad-hoc add-ons to gnubg.
> ...
>  
> > If the players' records are stored in a relation database it would be
> > relatively simple to do such a query.
> 
> I don't think we should be hooking directly to a relational
> database. We're much better off using a lowest-common-denominator
> export of raw data, e.g. CSV files

Yes, but it'll be hard to do anything inside gnubg with these data.
For example, just showing the current players' record dialog would
require us to read through the entire file and average a bunch of
numbers. Such operations are provided by RDBMS for our convinience. Of
course, this adds new dependencies.

Also, the suggested CSV file is not normalised leading to duplicate
data. 

It would also be quite flexible to add new fields without breaking all
previous versions.

As you can guess I'm not entirely conviced that we should stick with a
CSV file :-)

Jørn

pgpYCiNv9ZcKM.pgp
Description: PGP signature