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.