OT: MySQL versus PostgreSQL and database design

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:

formatting link
However, it seems to have a lot of bad reviews, saying it is lacking important information, especially in the index. Do you (or anyone else) have this book? If anyone does, it would be great to have another opinion on it.

Many thanks,

Chris

Reply to
Christopher Tidy
Loading thread data ...

Ah, sorry, I misunderstood (whew!). I guess this would depend on how different the event types are -- if they've all got exactly the same fields, then just having an event type field may well be the most logical approach. But if they're really *different* types of events (in spite of having the same fields), then breaking them up may sense.

No, that wouldn't be a worry (establishing a connection to the database takes a while, but not grabbing a table). On the other hand, I wouldn't expect filtering on an 'event type' field would be terribly time-consuming.

Sorry I'm being so wishy-washy on this one...

Besides, if you're anything like me, you'd never get around to learning it until there was a real project to learn on!

Vastly more satisfactory. That's what databases are good at.

Hopefully my wishy-washy answer above does a better job of explaining what I was trying to get at on this one.

formatting link

Surprising to see an O'Reilly get bad reviews (though I haven't looked at their DB books).

Reply to
Joe Pfeiffer

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.