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 >