bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [Bug-gnubg] Data collection


From: Chris W.
Subject: Re[2]: [Bug-gnubg] Data collection
Date: Fri, 15 Jun 2007 02:12:19 -0700

Hi Christian,

Thursday, June 14, 2007, 3:50:03 PM, you wrote:

CA> On 6/15/07, Chris W. <address@hidden> wrote:
>> Hello everyone,
>>
>> I've noticed an error in the information collected in the person table.  My 
>> nick, "ChrisW",
>> is listed twice -- once as "ChrisW", and once as "chrisw".  Can

CA> Some might call this a feature and not a bug. I prefer to keep things
CA> the way they are.

First of all, I apologize for the tone of my previous email. It was a 
frustrating
day.

I honestly cannot see how this can be called a feature. If we were talking about
files on different disk systems, then this would make perfect sense. Would you
reject a piece of mail, email or otherwise, simply because someone spelled your
name ChristiaN aNthon? Shouldn't data be Normalized rather than UnNormalized? I
can think of very few instances when key data should not be normalized.

> How difficult would it be to create an "export statistics" command so 
> individuals can

CA> You would have to decide on a universally accepted export format
CA> first. I know no such thing.

Well, CSV files have been around for decades. You could even go with the much
heralded XML format. ;-)

> Perhaps the best way to address the issue of which database to use, is to use
> none at all.  This low-tech method would reduce the complexity of the code 
> base,

CA> This seems plain wrong to me.

It's not SQL that I was taking issue with, it's the use of SQLite. There are
virtually no tools available for working with this product. SQLite Admin. is
decent but you'd have to spend $100 for the best app available. (SQLite Maestro)
What I was hoping for was an SQL database that can be connected to via ODBC.
SQLite doesn't provide that level of connectivity. As tightly controlled as
Snowie is, I can still read its Paradox tables by linking them to an Access
database via ODBC.

The point I'm trying to make here is that by choosing a database that can be
connected to easily, without the need of exporting, one can write an application
that will exceed the capabilities of that which is included in the product.

Snowie and GNUBG do a great job at helping a player improve his skills but,
both are woefully lacking when it comes to presenting data that shows the rate
of progress the player is making. By graphing the data over a period of time, it
would become clearly evident if a playing slump is due to errors made or simply
bad luck.

This is what I have in mind.

-- 
Best regards,
Chris
mailto:address@hidden





reply via email to

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