Thanks for the input guys.
I'll think about it in terms of responsibilities - you are right - I do tend to make things purely passive information blocks. This is probably the result of too early an introduction to
J2EE with its session beans and entity beans! So I tend to write verb-classes which do things (like session beans) and noun-classes which hold data (like entity beans) and don't have much behaviour. I'm deliberately modeling it in a J2EE sort of way so that if I need to port it to an EJB server it won't be too much of a conceptual leap.
I'll have a think about this.
Perhaps I need to go back to basics here and rethink the entire system. It's probably a bit late for this project, but for next time, maybe.
Warren, the relationship I am modelling is that a Job can have a number of different activities associated with it - so, for instance, a job might have 100 sms-send-activities - so one table for job, one for activity (to capture the idea of an "sms-send-activity"), and a table to capture the relationship, including the idea of "100-ness", if you see what I mean. You're right of course, it is a many-to-many relationship. Each activity can relate to a number of jobs - and each job might have a number of activities. Sorry, I was being a bit dense.