Consider this simple application in RUby on Rails:
Student & Teacher extends Person.
Person has 2 properties, name & age.
Student has 1 extra property, grade.
Teacher has 1 extra property, salary.
I want to store the student & teacher information in separate db tables. I want to take advantage of RoR's utility class ActiveRecord:Base to retrive data for these models. Because Person is not expected to be instantiated, I can mix it with Student & Teacher as follows:
class Student < ActiveRecord:Base
include Person
end
module Person
end
Question:
Is this the correct way of implementation?
How to implement this without creating a databse table called persons? I only want to generate 2 tables, namely students and teachers, and both should have the 3 properties mentioned above.
Person does not have to be a model - it can be a library/module (which you then mixin as per your example). You'd keep that in RAILS_ROOT/lib.
Your Student and Teacher classes can be models (which use AR::Base), and the person can just be a bunch of common methods used by both.
Alternatively, if your child class is far more complicated - look into "Single table inheritance" - the description of which is beyond the scope of this answer... but you can google for it.
Related
I have 4 Models, each defined as follows
--Model/Table--
Competition
Matches
Goals
Teams
These 4 models completes a season's worth of soccer league data. The relationship between these tables are already defined. Now, I want to create a class where it picks up data from all 4 models and generate 1, new class. Like so :
class CompetitionSeason < ApplicationRecord
# Use data from all 4 models to construct a soccer season class
end
That is my intention, but I'm not sure if this is the best practice for doing so. It feels... wrong on a Rails framework level. What is the best practice to achieve this?
Thank you.
You should really have another model called Season or some such which owns (has_(one|many)) each of the constituents.
I'm not sure what Competition is.
Match can belong to either a Competition or directly to Season. I don't get what Competition is so I can't make a good recommendation.
Goal should belong to Match or Competition, and not directly to Season. Season can still have many goals through Match or Competition.
Team should have a SeasonTeam junction table.
In rails web app, user can "make" a Document. There are different types of documents :
Loan
Business
Insurance
Each type of Document will have some things in common such as: account_num, doc_id, at least 1 name, but then they have different attributes.
For example:
Loan is only doc with a loan_type field
Business documents can have 1+ name attributes
If these docs may have different number of attributes, do they need to be completely separate models, or is there a way to incorporate a doc_type attribute for Document which then reveals what, and how many, attributes are associated with the Document? If so, what would that look like?
What you're describing is the express purpose of single-table inheritance in Rails.
Use one table with a super-set of all the fields from all the models. Add a type column, and then create your three models, inheriting from a base model, and you're pretty much done.
Depends on what you're going to need, but in general if your models have a strong commonality that part can all be in the same table, and include a type column that specifies the class name. This is called single table inheritance.
Any differences between the models give you some interesting options. If there are only a few differences, the columns could simply be included. If there are several, or the columns in question may be only sparsely populated, you can introduce a new table for the extra columns that belongs_to one of the models. For example, you could have an alternate_names table for businesses.
class AlternateNames < ActiveRecord::Base
belongs_to :business
end
In the unlikely case that you don't need to search on the extra data, you can even keep it in the same table, with a column named something like extra_data, and serialize a hash of extra attributes. Each class can handle this data as appropriate.
class Document < ActiveRecord::Base
# your code
serializes :extra_data
end
class Business < Document
def names
[name] + extra_data[:names]
end
end
There are two entities in my app: Class and Student, they are many-to-many relationship, like following:
My problem is that in my app, there are two status of student in a class: pass and fail. I don't know how to model it to class or student. For example, should I make another Entity to express the status of a student? Or just adding a status attribute to Class entity?
Presumably you can't add an attribute to class because then if 20 students are taking the same class there'll be only one attribute between them?
You'll need to add a separate entity which has a to-one relationship with both a class and a student and which contains the status. And in reciprocal both student and class will have a to-many relationship with statuses.
EDIT: I guess an alternative solution would be to insert the status directly in between your existing relationship. So a class has a set of statuses, and each status has a student.
So relationships would be one to many from class to statuses and many to one from statuses to students. There'd be no explicit relationship between class and student.
I would suggest having a third entity which expresses the status for the student in a specific class. For example a Set of "classStatuses". Since you might need to store other information later, for example grades, credits, assistance records, etc etc.
The final scheme would be something like
Class - Student in a many to many relation.
Student - ClassStatus in a one to many. (Picture is as an array of the classes the student is taking with its respective status)
This way you can search for the students in a class, search for the classes a student is taking, check the status of the class.
I'm building a course application system. The high school, undergraduate and graduate students are all able to apply for this course. They have to fill out some application form.
However, their information forms are similar, but not exactly the same. Every student has name, phone number, email, address, etc. But only undergraduate students have to provide their GPA, and graduate students is required to tell which lab they are researching at. There are other subtle differences...
So how should I deal with this? Make a big table, but leave 'GPA' column of high school students NULL? Or use three separate tables?
Moreover, there are some relation between Student(or, in three tables case, HighSchoolStudent, UndergraduateStudent and GraduateStudent) and other models. For instance, Course has many Students, Student has many Questions, and so on.
You can use a combination of STI and Store feature achieve this.
Declare a base model for Student with a text column called settings.
class Student < ActiveRecord::Base
store :settings
# name, email, phone, address etc..
end
class HighSchoolStudent < Student
# declare HighSchoolStudent specific attributes
store_accessor :settings, :gpa
end
class UndergraduateStudent < Student
# declare UndergraduateStudent specific attributes
store_accessor :settings, :attr1
end
class GraduateStudent< Student
# declare GraduateStudent specific attributes
store_accessor :settings, :attr2
end
In the sample above, instances of HighSchoolStudent will have an attribute called gpa.
You could go with the option you thought of like leaving GPA null, and set up custom validations for the model so it only checks depending on the student type. Single table inheritance is also an option, where you specify the different class names to use in a column on the database table, and then you simply add these classes in the model directory. You can see some documentation on it here: http://api.rubyonrails.org/classes/ActiveRecord/Base.html
I haven't tried STI before, but given what you stated above, I'd probably go for that route, branch off my code and would see how it pans out.
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