Ah. Now you see, that makes sense when its laid out on paper. I was considering having to go with a separate Model that would be the link between them.
The relationships I had sorted out in my mind went something like this: Employee hasMany RatingsMade, Employer hasMany RatingsMade and Ratings hasMany RatingsMade RatingsMade belongsTo Employee, Employer & Ratings. I sometimes have issues trying to lock down the types of relationships that need to be enforced between Models. Do you have any helpful ideas/ hints that you found helped you? On Feb 5, 4:36 pm, brian <[email protected]> wrote: > I think 3 columns should be sufficient, although having a PK wouldn't > hurt (and may help in some circumstances). > > employers_ratings ( > employer_id, > employee_id, > rating_id, > UNIQUE (employer_id, employee_id) > ) > > Assuming that you'll be getting the employee_id from the session this > should be pretty straightforward. > > Employee hasMany Rating > Employer HABTM Rating > Rating HABTM Employer > > The unique constraint would keep an employee from being able to rate > the same employer more than once. > > On Thu, Feb 5, 2009 at 4:46 PM, garbetjie <[email protected]> wrote: > > > Hi all (again). > > > I have a different question this time. Allow me to elaborate on the > > situation... > > Let's say I have three tables: employees, employers and ratings. > > > Employees: Contains employee information > > Employers: Contains employer information > > Ratings: Contains various ratings with weightings available to > > employee. > > > Each employee has the ability to rate an employer. Employers cannot > > rate employees, and each rating links up with one of the ratings > > available in the Ratings table. > > > I've been struggling for hours on trying to sort out this database > > layout, yet I am so sure that it should be relatively simple. > > > I would normally just create a database table called > > "ratings_made" (or something to that effect), and have four columns: > > ID (The unique primary key) > > EmployeeID (The ID of the employee that placed the rating) > > EmployerID (The ID of the employer that received the rating) > > RatingID (The ID of the rating placed) > > > In my mind, this equates to a (relatively) straightforward query, > > however, I am having trouble "translating" this into CakePHP terms (I > > am still relatively N00bus on this - I only started about a week ago > > O_o). > > > I do know that my database layout skills are perhaps not the best, but > > any suggestions are welcome and *very* much appreciated. > > > *g --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
