2 Replies Latest reply on Feb 22, 2015 7:34 PM by FentonJones

    Help with tables

    MarkBanin

      Title

      Help with tables

      Post

      Hi Everyone

      I'm a bit of a newbie.....

      I'm setting up a database for use as in a recruitment agency that supplies short term candidates (not temps).

      Please let me know if my premise here is wrong.....

      Now I understand that your database should only contain "one to many" relationships

      * an employer can have more than one candidate (employed)

      *  a employer can have more than one candidate (interviewed)

      * We can place a candidate at more than one employer (usually at different times in their career)

      * a candidate can go for many interviews

      2) I believe I need 4 tables
       
      Table 1) Clients

      Table 2) Candidates

       

      So I guess I need a table for "interviews" and a table for "placements" as well? (making a total of four)

      Which I think resolves the "many to many" relationship between employers and candidates

      Is this correct?  Or am I thinking about this all wrong...

      Thanks in advance for your help.

      Mark

       

       

        • 1. Re: Help with tables
          philmodjunk

          Now I understand that your database should only contain "one to many" relationships

          Not really. One to One relationships can be quite useful. And some special use relationships may look like "many to many" due to "crowsfeet" at both ends of the relationship line and yet be very useful relationships to use in your database.

          4 tables may be a good data model or you might set up one join table for both interviews and placement by using the same table for both, but with a field that identifies the record as either an "interview" or a "placement". I'm not recommending for either option, just pointing out possible options to consider.

          • 2. Re: Help with tables
            FentonJones

            Mark, it seems good to me. I worked on a similar database, and yours sounds much the same. We had a tabler named "Status", which could have an "Interview" within the field "Status" (as it had a few other statuses also). We had a separate table for "Calls" (just for Candidates; we had a separate ones for "Client Contacts", and for their "Contact Calls"), which would contain the actual "meeting", for the "interview". Both of these tables had a lot of records, with some more important than others.

            Placements did not have a lot of records, but each was critical. They linked together a specific group of a "Client" and "Candidate" (we also had another table for "Jobs", as Client could have multiple jobs, each of which could have more than one possible Placements (do to multiple "positions" for one Job). 

            So, four tables is the least you need, but it sounds good for a start.