I guess the only idea I have is to put all the fields from both of the above tables into one client table and only fill in the fields I need when entering a new client. Not glamourous but I guess it will do the job. The other idea is to setup three different client tables. Any suggestions?
I'd suggest 4 tables (possibly more
the parent table say TBLCustomer contains the key details of a customer
eg name, invoiving address, contact details etc. (include any common data from all 3 job types
you can then link to customer from, say a photo register.
you then have a child table for each type containing their unique data. you may need to implement more tables if you find data is repeating. (for example you may need to explode the wedding photo further).
If your db supports exclusive 1:1 joins (ie the :1 can only be one of n tables) then its pretty easy to implement, otherwise its down to implementing that as part of the business logic.
Personally I'm not sure that this is the 'right' model, but its perfectly tenable. I have doubts about storing attributes which are probably photo (image) related in a customer table. I think you are exposed by storing contact details in the customer table(s), you possibly need to consider a contact type and then store those contacts associatiing them to customer. That way round you can deal with large companies which may have multiple art directors, producers, assistants etc..... (all of whom may have multiple tel / fax / email / web contact data). It also may get you out of the tricky situation of the same sex marriage / partnership of assigning someone to 'groom' and someone else to 'bride'. Your model could then also support the situation say where someone may want photographs of a marrige re-dedication wher ethe labels are 'husband' & 'wife'. If your system generates reports or invoices which could be seen by the customer then it could avoid potentail problems.