Hi Joe,
Thanks for the thoughts. Once again, sorry I've been slow to reply. I'm working on several projects at once.
No, I don't think I've conveyed my meaning correctly. It would not be one event per table, but one type of event per table. I was thinking of sorting the events into different tables so that each table contains one type of event - specifically a subset of events that I'm likely to want to retrieve all at once, without any sorting.
Does establishing a connection to a particular table take a significant period of time, such that I would need to minimise the number of connections to tables that I'm going to open and close?
I'm sure you're right here. Ultimately, this may not be the simplest beginner's database project I could choose, but it certainly isn't the most complicated either.
I was guessing that using the database for searching and sorting as much as possible would be more satisfactory than using a PHP script for the same purpose.
I'm afraid I don't quite understand why this is the case. Possibly my explanation has been too abstract. But if it adds anything, each event will have the same fields in a row, with no empty fields. But I will never want to retrieve all the events at once. I will always want to retrieve a subset of the events, and I was thinking of sorting them into tables according to subset, so that the database didn't have any sorting to do when it came to retrieve the events. Instead it would just need to sort the events when inserting them into the different tables.
You also mentioned O'Reilly books a while back. I already have Jonathan Gennick's "SQL Pocket Guide", a great little book which explains the differences between the major SQL database systems.
I had a look on Amazon and the only suitable O'Reilly PostgreSQL book I could find was this one:
Many thanks,
Chris