Improve reduce functions of SQLite3 request

[Steffen Mutter]

Dennis Lee Bieber wrote:

> 	Which does, to me, imply an unnormalized database. The
> "team/category" should be a separate field.

> club(*ID*, name)
>
> team(*ID*, /club/, category)
>
> {where *..* is primary key, /../ is a foreign key}

You are right, but as I mentioned above I had to use some data stored
somwhere, strip it out of html, seperate it and store it in a database,
where it is useful.
To be specific: the only thing really needed is the club number. Which
team plays in the specific league is not really important, cause a club
can only have one team in a league.

> and league should probably be another table (and "club" may have a
> /league/ entry).

The way I did it is this:
store all data for a complete season in one table. There are more tables
especially for the gyms or stadium data if more information is requested
by the user.
My plan is to do it better and user friendly than the commercial stuff,
but I need their results and design to get my thing to work. I offer the
game-plans as html for direct viewing and cvs and pdf files for
download - onother feature no commercial site offers.

> 	Yes, that would imply using JOINs to get a full identifier, and
> maybe more complex GROUP BY terms...

Certainly a more complex normalization would imply a complete
reprogramming of all SQL-requests send to the DB. I am a great fan of SQ
Lite, because it is fast, easy to use and very easy to maintain and
backup. (just a nice rsync job backups all without any hassle)

I prefer you help next time I run into a problem I can't fix on my own
:-)

>> Woha!
>> Why didn't I get this out by myself?

> 	Well, I only got the idea after someone else mentioned using min();
> but I don't recall if they had GROUP BY in that suggestion. GROUP BY
> ensures the min() only applies when the "nr" is the same.

I played around with min() already but I got stuck with the 'DISTINCT'
at the beginning so I got only a single result. This SQL spell you were
casting for me gave me a deeper understanding, how SQL works and what
can be done with it. Thanks :-) 

Actually I am fixing bugs and think about the user managment and
permission handling and privacy of data.

Just give you a peek:
referees need to be kept safe. 
But they need to be planned and stored in the DB.
How to handle this?
I think I use GnuPG. 
Every referee and referee-date-planner needs a private and public key so
only these persons can see it, the planner every referee he dates and
the referee only these games he is planned for.

 You see: a lot of work to do - after fixing some bugs and get the
<select id="team" size=7 multiple> to work, that will be a big task...