Thanks for all the replies. I think for my purposes, I'll just make a
large table that has fields for everything. But I was thinking about a
more scalable solution:

Make unique id for both table a and table be with an auto increment
numerical field, but with talbe b starting at some very large value.

Maintain two tables with the two types of events. Generate the third table
that links them as needed by joining the two table by their unique id and
then making a second field "table" have a if the id is 0-10000 and "b" if
the id is 50000-60000 (or whatever the numbers are). When I want to access
both tables, I can just query all in the generated table and if table=a,
do something and if table=b do something else for each entry. 

Ideally, I guess the linking table would contain fields that table a and
table b share (like time and date) but I think this would work without too
much extra scripting on the query side.

Ben 





On Tue, 17 Jul 2001, Troy.A Johnson wrote:

> 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.
> 
> 
> _______________________________________________
> tclug-list mailing list
> tclug-list at mn-linux.org
> https://mailman.mn-linux.org/mailman/listinfo/tclug-list
>