In case things screw up on you (or you do it to them, whichever ;-) you might want to include some extra ids in your tables, and make them 'auto_increment' and 'primary key' fields, so when it is time to "adjust" (or delete) the data, you control exactly what you're changing: table: events ------------- id type common_item -- ---- ----------- 1 a common1 2 b common2 3 a common3 4 b common4 table: a_events --------------- id event_id info1 info2 -- -------- ----- ----- 1 1 stuff1 stuff2 2 3 stuff3 stuff4 table: b_events --------------- id event_id other1 other2 other3 -- -------- ------ ------ ------ 1 2 junk1 junk2 junk3 2 4 data1 data2 data3 I don't know which way will work best for you but it may be helpful to know you can probably go back and forth with relative ease. Good luck, Troy >>> lueyb at gridley.acns.carleton.edu 07/16/01 09:45PM >>> > I've seen it done both ways. The first way is arguably the simplest, > but the second way to more true to the relational model of data. > Adding a event type code to distinguish the two types is not a bad > idea either, but not a requirement. Is it possible to have three databases: One would be the "glue" UniqueID type 1 a 2 b 3 a table a would be 1 info1 info2 3 stuff stuff2 table b would be 2 otherformatted stuff with more fields 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. 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.