This is pretty exactly like a typical Customer to Invoice to Line Items from Products. That's 4 tables. It cannot be done with less. You still need an Invoice, because a sale happens at a specific time, with 1 Customer, and 1 or more Line Items (copies of images in this case). An Invoice is basically a shell to contain line items. You are selling copies of images, not a one-time sale of the original image; hence the Images are the Products. You want to set their Image ID (unique in the Images table) into the Line Items.
Thanks for the response, Fenton!
It is a similar situation, however, we won't be invoicing here. This is just the selection process of the images that the family wants for a photo album or various other products that we will actually be invoicing for later.
Here we may have several different family members (bride, brides family, grooms family, grandma, etc.) sitting down and going thru the pictures for the ones they each want for whatever product they want. So basically it's like having several lists going all at the same time.
So, we want to be able to have those people in Customers and somehow select however many are there at one sitting so that they appear on the interface and we can somehow put an X, click a button or whatever by their name for every picture each individual wants as we go thru them. I made a play db of Customers, Cust-Img and Images. I think I need to have the layout looking at the Images table so I can step thru the pix one by one. Maybe I do need a 4th table like you say as I can't figure out quite how to mark my X or make the connection. Wouldn't the match of keys from Customers to Images in the Cust-Img table cover the multiple customers to each image part?
I guess my biggest problem is that I don't know how to get the several customers on the interface at one time (maybe a portal?) so I can just have a button or whatever put the match of the customer key to the image key in the cust-img table.
I'd appreciate a little more input if you have the time.
Even though it isn't really an invoice yet, you are collecting the data you need to invoice each individual.
What you have here is a many to many relationship. You have many customers who are each selecting many pictures. A join table (which functions just like the line items table in an invoice) will do the trick:
Showing the match fields involved:
Customers::CustomerID = PicturesSelected::CustomerID
Pictures:: PictureID = PicturesSelected:: PictureID
Each time a customer selects a picture, create a new record in PIcturesSelected with the customer's ID and the Picture's ID.
You will likely need additional tables in PicturesSelected to document the options for each print such as size and number of copies.
I can imagine a layout where you use one more table: Weddings (or events if you photograph other things besides weddings).
Create a portal on your layout that lists all your customers for a given wedding and another portal that displays one picture at a time. Select one picture at a time and then click on customer names to select them in so you can document the order details for that picture. (You can place detail fields from PIcturesSelected on your layout and with the correct design, clicking a customer name selects them so that the detail fields point to a matching record in PIcturesSelected for that customer.
THis is just a general outline of the technique. There are a lot of details to work out and scripts to write and assign to button on the layout, but maybe it will get you pointed in the right direction.