Ahhh, gotcha! What you've got, if I'm reading correctly, is a many-to-many relationship: Any
One Client can have
Many Job Listings, and any
One Job Listing can be sent to
Many Clients.
You'll need three tables: tableClients, tableListings, and tablePostings.
tableClients lists all your client-specific information; company name, address, contact person, fax number, etc.
tableListings lists all of your joblisting-specific information; you know the fields better than I do.
tablePostings is the key that will make your life easier; it should have a field of the same type as your Primary Key from your Client table (Long Integer for Autonumber, Text for Text) and a field of the same type as your Primary Key for the Listings table. These are called Foreign Keys. Additionally because of your needs, this table should probably have at least two other fields: An autonumber field (Primary Key) of its own, and a date field that stores the date you mailed out that job listing to that business.
Now, you'll still be making 5000-10000 entries a week, but they will be
one field entries, and we can probably even speed that up
if you're sending every listing to every client, or at least a set of listings to a set of clients. That will take more time though. I would recommend you include a field in each of your 'main' tables that lists the 'type'; if you've got White-Collar clients and White-Collar jobs, Technical clients and Technical Jobs, Semiskilled clients and Semiskilled jobs, etc.
Right now you should spend some of that time you're going to save on data entry to read this article on "database normalization":
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q100139
Post back if you have further questions. Subforms can be a little weird in a many-to-many relationship, basically you will be making a query that holds the Postings table and (whatever the side of the relationship is that is
not on the main form), and using that as the record source for your subform.