Joel D Canfield noted: > single table and added a field for 'event_category' rather than having 5 individual tables. >>me too :) - at least then, if you add a new event category, you're just >>adding data to that table, not an entirely new table. Hi Joel, I'm kind of waffling. I agree that if Chris has five tables with identical structures he should be able to collapse those into a single table and that the single table would be easier to work with. However ... we really don't know very much about what Chris is trying to do. Nor do we know what these 'event categories' are. If the events are disparate enough then perhaps they ought to have different table structures.  With the limited scope of information provided I think the answer is good. Just noting that what we are suggesting here may turn out to be a temporary or a suboptimal solution that eventually paints Chris into a corner. 'Quick & Dirty' database design often leads to considerable time and pain later. Cautiously, RonL.  Being the 'imaginative' sort, I imagined Chris's "events" to be various fundraisers all supporting a common charity. A band plays a pro bono dance. A multi-site softball tournament with entry fees is held. A magician gives numerous performances during a community bazaar. A multi-week 'football pool' event is also held. Etc. A single table (or a single table structure) may not be the best way to capture/report/present information for each or all of these individual events.