Improve reduce functions of SQLite3 request

[Steffen Mutter]

Dennis Lee Bieber wrote:

> 	If you use separate tables you make it more difficult to generate
> the SQL (as you have to create the SQL with the season specific table
> name, instead of just using a "where ...." clause to restrict data), and
> lose the potential to produce reports covering multiple seasons.

I think, when the season is over, the table will be closed to change its
contents, so the history data for this season will be written to
the data tables of the clubs or users. 
You gave me a lot of input about databases and how to put them together.
I removed the double time/data stuff from the seasons tables and it
works fine I made a speed-test and it is a bit faster now.

Now there are some features missing, I will put into, a checkbox 'only
today' shows you only the games played today. In combination with a
checkbox 'games without result' gives the visitor an easy way to find
out if a result wasn't reported yet - interesting for coaches, league
managers and players, too.

> 	<snip> 
> 	Have you considered defining "views" and "triggers" -- based upon
> the user privileges you run queries using views that only expose the
> permitted data (and use triggers to permit properly updating the
> underlying tables when edited).

I will do the user managment based on the tables in the
user/club/federation tables I am actually thinking about - views are an
interesting feature. 
This is very complex, the user table will be the beginning to start
from, where the personal data is stored. userID, name, gender, date of
birth, club and e-mail as must haves. 
Based on this there is a role table, where the roles for all persons for
an area in the system will be placed. Not very easy to do, but an
interesting task to plan...

> 	Fuller DBMS would allow you to define access controls on individual
> columns -- though it would mean you couldn't made the main database
> connection until you know the access level of the user, as you'd connect
> using a name/password specific to the level of the user (I'm not saying
> each user has a database name/password, though that is an alternative --
> it just means you'd have to do a lot of database administration each
> time a user is created).

Hopefully my python code will handle that for me :-)

I really like SQLite, very easy to use and to backup.
The idea behind the user managment is, that the users manage themselves,
I will only step in when something does not work as it should...