How can I make domain classes to make tables in Grails which 'share' data but do not 'belong' to the other? For example, I want to make 2 tables:
Person Table with 2 major columns
Name - Skills
Larry - Jumping, Laughing, Punching
Curly - Crying, Laughing
Moe - Punching, Dancing
Skill Table with 2 major columns
Name - Persons
Jumping - Larry
Crying - Curly
Laughing - Larry, Curly
Punching - Larry, Moe
Dancing - Moe
Deleting a Skill also removes that skill in the Person table, while deleting a Person also removes that person in the Skills table. I tried the domain class below, but when I generate views, I'm unable to enter multiple Skills per Person and vice versa.
class Skill {
String name
Person person
static hasMany = [person: Person]
class Person {
String name
Skill skill
static hasMany = [skill: Skill]
I've looked at other posts, but the solutions often have 3 or more classes (usually Book, Author, Chapter) and seem very complicated.
Thanks in advance
I think you need:
class Skill {
String name
}
class Person {
String name
static hasMany = [skills: Skill]
}
Grails will create a 3rd table called something like PERSON_SKILL which will have person_id and skill_id as columns. When editing what skills your person objects have, you are really editing records in this 3rd table.
Deleting a person record will delete all corresponding person_skill records for the person_id.
To delete a skill record, you'll need to manually delete all person_skill records for the skill_id first, before the skill record can be deleted.
Effectively, skill is acting as a static data table so doesn't need to belong to another domain object. I use several instances of this in my systems and Grails/GORM seems to automatically generate the obj1_by_obj2 link table for the ids.
I think your views/controllers/services can just deal with the person.skills collection (i.e. add, remove) then leave Grails to persist the updated collection to this 3rd table.
Give that a go.
Related
I will preface it by saying I'm a database person, moving into .NET, MVC, EF etc. So I fully understand about joins and foreign keys and so on but I am struggling with the EF side.
I worked through a tutorial where we did the following:
create a Student table (StudentID and personal details), a Course table (CourseID and subject details), and an Enrollment table (EnrollmentID, student and course IDs and the grade given to that student for that class).
create Models, Controllers and Views for Student and Enrollment entities to allow editing the name of a Student, enrolling a student for a class and giving them a grade, list out all enrollments, etc.
In that tutorial the Enrollments table is (what I know as) a "bridge" table because student to class is a many-to-many relationship.
So do I only need this "intermediate" model/view/controller if it's a many-to-many scenario like this?
The actual structure I want to program is:
Article (ArticleID, title, author, summary, content...) is a member of a
Category (CategoryID, title, description, ...)
Then I want to have a drop down list (or whatever UI element) of Categories of which clicking on the selected Category will give a page with a table of Title/Author/Summary of the articles that go in that category.
If an Article can be in more than one category ("Effective Use of Catnip" could be under both "Playing Games with Cats" and "Life Hacks") is that where I would need a 'bridge' table?
Please can someone explain in simple terms - whether I am just being put off by the "many to many" nature of the data in that tutorial, or if the 'bridge' table structure is more fundamental to EF for navigating a PK/FK relationship.
I think the tutorial you are reading is trying to introduce you to the basic concepts of EF. If you have a many-to-many relationship, on database side you will always have three tables:
Student
Course
Enrollment (Student_Id, Course_Id)
On EF world, you can represent those three tables as three different entities. However, if you want to have a more "natural" way of representing the relation between Students and Courses, EF allows you to declare many-to-many as two lists:
public class Student {
... properties
virtual List<Course> Courses;
}
public class Course {
... properties
virtual List<Student> Students;
}
However, you need to instruct EF how this references on both side needs to be treated. For that, you can use fluent API. With this fluent API you can define the table name that references both tables/entities:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<Student>()
.HasMany<Course>(s => s.Courses)
.WithMany(c => c.Students)
.Map(cs =>
{
cs.MapLeftKey("StudentRefId");
cs.MapRightKey("CourseRefId");
cs.ToTable("StudentCourse");
});
}
Check this article explaining the M:N relationship using fluent library API. Is really simple, and with that you don't need this additional element on the middle.
In terms of UI, you just need to select the list of courses the student want to take, or the list of students the course has to have. Is up to you how you want to present the information to the user, as both functionalities (students taking courses and courses defining its students) point to the same m:n relation.
I think a simple way can be to show a </select> list with the students, and then show the list of courses he can apply to.
The project you want to create uses the same ideas. Basically, with EF you will always need to think in terms of "tables". It is true that EF allows you to abstract your tables to entities, but still you need to follow some rules. To sum up: you are right. The "bridge" table is where you need to store the many-to-many relationships.
Lets say a relationship is described as:
A company has many employees
A company has many departments
A department has many employees
So, something like this;
Company -<< Departments >>- Employees
If department table has a basic structure of:
// Pseduocode
company_id // Foreign key
department_id // Primary key
[employees] // Array or collection of employees
If we go back to this phrase;
A Company has many employees
Does this mean that the employee table needs or requires a reference for the company_id too?
So, Employee would be:
employee_id
company_id // I'm not sure if this is requried or not
department_id
I'm intending to hopefully abstract this data into a contracts table in case of employees are freelancers/contracters, etc or have multiple employees.
But for now..
My question is:
Does my employee table require a reference to the company table, or is the company reference implied via the department table?
Many thanks
Question is: do you need a straight connection between Company and Employee? If you do, add it, if not then yes, the connection is implied through Department.
EDIT:
Technically, your Department table does not need a list of Employees. Each row of Employee table has a reference ID to Department, that's enough.
Check this out for more information.
The relationship is implied through the department, so you don't conceptually need it. Adding it, would be an example of denormalisation, and would allow inconsistencies to crop up. For example, you might have company_1 with department_1 and company_2. Now employee_1 might be linked to department_1 but company_2, because of some flaw/bug in the application code. There's no way to express this constraint as a SQL schema, so you'd have to go with more complicated stuff such as triggers, or application code checks etc.
However, sometimes you only need info about companies and employees, but not about departments. If it's really performance critical, doing the extra join with departments in order to find the company for an employee or the employees for a company might not cut it, so you'll just have to live with the denormalisation.
You probably do not need to link Company with Employee. The relation between Departement and Company already do the job. You may need it only if there are existing particular cases requiring this relationship.
I'm a bit confused on what a many to many relationship is. I'm wondering if the following is a many to many relationship:
A student at a school has many clubs. A club at a school has many students. Let's say that the student has many attributes: firstname, lastname, phone, age, email, etc. A club only has one attribute: a name.
When I make a new club, I want to be able to give the club a name and one or more students. Upon making the club, I want that club to be associated with those students and those students to be associated with that club.
When I make a new student, I want to be able to give the student a firstname, last name, etc, and one or more clubs. Upon making the student, I want that student to be associated with those clubs and those clubs to be associated with that student.
I also want to display a club's students and a student's clubs on their show pages.
I've read that a many to many relationship is when you have a join table that lets you access common attributes of the resulting students and clubs, but there are no common attributes in my case.
Do I have a many to many relationship here? If so, do I use a HABTM or has_many, through relationship?
Actually yes you DO have common attributes.
You stated yourself that a Student has many Clubs
And a Club has many Students.
What is in common? Students and Clubs.
What now follows is to define what a Student and a Club actually are, which you already did.
A Student is a combination of firstname, last name, etc... What you have not specified is what makes a Student UNIQUE. A club also must be defined as to what will make it UNIQUE. While for academic purposes, you could say the name is what makes it unique, in real live, that would probably not be the best solution.
Usually for performance purposes, each student is given a unique Autoincrement ID (which is a number).
Same thing can be done with the Club.
You create a 3rd table which is what creates the Many to Many relation.
In that 3rd table, you have 2 columns. One with the Unique Index for the Student, and the other column with the Unique Index for the Club. You simply add an entry on that table in which you wish to relate a student to a club.
Since you can have many students assigned to the same club, and you can have many clubs assigned to the same student, you have a many to many relation.
Edit: As mentioned in another answer, your 3rd table should also declare the combined indexes as unique, so that you don't add the same entry multiple times.
You have a many to many
Create an id for each table that is unique for that table typically an auto incrementing int.
Then a third table that is a junction/intersect table call it X.
Put a row in X with the student id and club id if the student has the club and vice versa. It would have a unique composite key in table X across both id's in it.
The composite would guarantee no duplicate rows in X
Yes indeed there is a many-to-many relationship here, use HABTM. Also, why do you say that there are no attributes in common? Club names and student names are definitely common attributes in this case.
I'm new to CoreData structure, I have two classes one is "Person.h" and another is "Education.h" which has one to many relations ship Person<--->> Education`.
Here's the attributes for each classes,
Person.h
personID (unique) Number
pName String
pAge Number
educations Set
here, p stands for person
Education.h
educationID (unique) Number
eName String
eState Number
eStarted String
eCompleted String
eCenterName String
eBy Person
here, e stands for education
Ok, now I want to fetch (all / some) education details for a Person. I've successfully inserted records in both the classes with proper inputs. How to get this done? Any suggestion? Please consider me to correcting, even if this flow would not clear to you (or its wrong).
Thanks,
Hagile
Normally you'd have a Core Data relationship on Person that points to the Education entity, configured as to-many. Then once you have an instance of Person, you just look up the value of that relationship like you'd look up the value of any property. You get back a collection of zero or more related Education instances, and you don't need to do an additional fetch.
Your eBy relationship on Education suggests that you're thinking of this as if you were working with SQL. With Core Data it's normal to have a to-many relationship defined on the entity that has the relationship (and indeed, eBy should really have an inverse relationship).
I am am developing a recruitment application for storing records of people who come for an interview. So I have two models - Applicant & Employee which seem like one in OO sense. i.e. Employee was earlier an applicant. Therefore I am planning to create a Single table inheritance like:
Applicant < Person
Employee < Person
All the fields of Applicant are there in Employee. Employee has several other fields that are not in Applicant.
Am I correct with this plan. I have another similar scenario to deal with - prospects & clients.
Update: As I am working more and more with STI, I am starting to dislike it.
As per my personal opinion , in OO point of view you are correct.
Applicant < Person
Employee < Person
But when it comes to database/ tables i will go for a one table called 'persons' (Person) that has all the columns for both 'Applicant' and 'Employee' and have a column with a flag indicating whether the Person is an Applicant or Employee
NOTE :: but this is only true if you have ONLY 'several other fields' not many
HTH
sameera