> Then my script could foreach in table glue, if type=a, get id, query table
> a, do stuff, and if typ=b, get id, query table b, etc.

There should be no need for this complexity in the front end. Use
massively complex and ugly SQL instead. ;)

Something like:

select * from
  (select date, eventtype1stuff_1, eventtype1stuff_2, null, null from
eventtype1
  union
  select date, null, null, eventtype2stuff_1, eventtype2stuff_2 from
eventtype2)
order by date desc;

Does your head hurt yet? ;)

Untested so the syntax may not be quite right. But you get the idea. And
of course MySQL doesn't do subselects so you have to do it your way. ;)

And I recommend taking an SQL class. Or at least reading a good book. ;)
(The Practical SQL Handbook Third Edition is what my class used. I still
find it handy for figuring out all the wacky stuff you can do with
subselects and such that I've only just scratched the surface on...)

> The main problem with this is maintaining the unique id numbers that join
> these tables. Can I somehow link these tables in mysql so when I add an
> item in table b, an entry is added to table glue, or do I manually (ie
> with scripts) need to maintain the syncing of these tables. It is my
> (naive?) impression that it what a relational database is for, but I can't
> find info on mysql on linking tables like this.

Postgresql has a serial datatype/serial generator. Looking through the
MySQL docs it doesn't seem to have one. It also seems the MySQL
developers really are arrogant, only concerned about speed, and no care
to being anything but a totally minimal SQL implementation. ;P

Use MySQL if you want a cheezy little web page.

Use Postgresql if you want to develop a real DB app or learn how to
develop a real DB app. And the latest Postgresql 7.1 seems to be hella
fast, they apparently implemented journaling (or maybe phase tree?)
within the DB files so it runs in async mode by default now. Whoo.

I'm a Postgresql fan if you haven't noticed. ;)