> 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. ;)