I have a standard devise user model with the usual fields.
This is for a situation where people are either looking for a place to stay, or they have a place to stay. So I have two categories of user that a person can be. These two categories are very distinct (i.e. a person looking for a place to stay will have very different fields to a person who has a place to stay).
So a User has:
User: name, email, password, profile_id
A User can also have a Profile (i.e. they are looking for a house).
Profile: age, sexuality, religion, occupation
That's what I have at the moment. Now I need to change that slightly, so a User can have a profile OR... they can have a House (i.e. they have a house and are looking for more people):
House: price_per_week, address, etc
How best to model this in ActiveRecord? Polymorphic association of some kind?
I've found in general that polymorphic relationships don't work well over time if the objects they are modeling are even mildly different. For your case I'd recommend keeping the two objects separate.
In general, the best way is to consider the way you want to retrieve the data. For example, I'd imagine you want to access both:
#user.house
or
#user.profile
So I'd recommend beginning by setting up relationships (that can be optional) between the users table and both the profiles and houses table. I'd also add a type field that can be used to determine which of the two types the users are.
This allows users to be of either type and allows them to have both a profile and a house.
So both houses and profiles belong_to users, and users have_many (or have_one) houses and profiles
Related
I have three models: Company, User and Employment. Each Company has many users though their Employments, and a user might belong to several companies through his employments.
Now, the tricky part: let's say my User1 belongs to 2 companies. He is SUPER_ADMIN in the first compnay, but just BASIC_USER in the second one. What would be the best way to define his roles ?
I used to have a simple has_many relationship between Company and User, which allowed me to simply set a is_admin attr on my User, but obviously this won't do with the new HMT relationship.
I thought of defining an array of IDs for each company, that would include the IDs of each admin user, but I'm pretty sure there is a cleaner way around.
In above scenario, you can use intermediate table i.e. Employment table to save all details of a user and it's associate company.
As Employment table will have ids of both user & company it will be easy for you to keep extra information related to user and company. Just add role column in this and use this to get information
I’m working with Ruby on Rails, but this question applies to application/database model design in general. I want to model many types of people such as User (someone who can log in), Employee, and Customer. Each of these has common attributes like name and email that should be part of a Person superclass. Each type also has other more specific attributes. A Person can be one or more of these roles (someone can be both an employee and a customer).
In code, the appropriate structure seems like a superclass/subclass relationship, but from a database normalization perspective, there should be a Customer table that references the Person table for its common attributes.
I need to decide how to combine these two approaches.
For example, I want to be able to create a Customer by Customer.create(name: “Johnny Appleseed”, favorite_product: widget) and query Employee.where(email: “someone#company.com”), and avoid duplicating Person fields on every role model. That way I can change the way I model a Person without needing to update all the other tables with the same changes.
It would be better if you use Single Table Inheritance.
You can start from this tutorial https://samurails.com/tutorial/single-table-inheritance-with-rails-4-part-1/
When is the correct time to use STI in a Rails app? After a lot of reading (including this excellent Railscast) I'm still unsure what is the best approach for my needs.
This (contrived) example illustrates my dilemma.
Lets say a User class could categorized in several sub-classes, including Doctors and Patients. These are more than simple roles, with key data and logic differences.
A Doctor has certain database fields (e.g., qualification, speciality), certain view logic (e.g. if User.doctor? then display list of patients), and certain logic and roles (e.g. can manage patient records).
A Patient has different database fields (e.g., blood type), view logic (e.g. if User.patient? then display list of treatments), and logic (e.g. can edit appointments).
Both Doctors and Patients have :username, :email, :password fields in common, as well as a considerable amount of logic throughout the remainder of the app (e.g., User has_many :comments, :messages, etc ).
From my reading, the fact that Patients and Doctors have different logic requirements suggests STI may be appropriate. But with different database fields, polymorphic may be a better approach.
BUT....
A User may be both a Doctor and a Patient simultaneously.
Is there a "best approach" to this problem?
STI uses a single column to determine the object's type.
At first glance this would indicate you'd need to have User, Doctor, Patient, and DoctorPatient classes, which to me, seems a little loopy. It could potentially get even loopier if other types are added.
Moving Doctor, Patient, etc. functionality into another class (and table) seems like it'd make more sense, without knowing anything more, but other folks may have more useful input.
I have an interesting problem that I never had to deal with before. I'm looking for the best way to approach it.
I'm creating an admin site linking students to virtual machines. A Student can sign up for multiple courses and has one virtual_machine_id which depends on the combination of courses they take. An Admin can create new courses and (separately) map combinations of courses to specific virtual_machine_ids.
1) What's the best way to associate a combination of variable elements with a specific id? If the elements were fixed, I would create a table with columns for each element and one column for the virtual_machine_id. But since these elements can change (as admins add or remove courses), how do I map them in a way that I can easily query for a combination and it's associated id?
2) Right now, I have Students mapped to Courses using a has_many :through association and a third table with student_id and course_id. Is this the right way if I need to collect combinations of courses and assign the entire combination a single virtual_machine_id (i can't assign the id to the student because they could potentially have more than one virtual_machine depending on how many courses they take)
I was looking at the EAV (entity-attribute-value) model as a solution but the general consensus seems to be that it's a bad a idea because you lose some ActiveRecord features.
If you wish to use EAV with ActiveRecord ORM you can look at hydra_attribute gem which allows to create new attributes in runtime and has possibility to find/sort/group by them.
Currently the 0.3.2 version doesn't support attribute sets but in the next release I'll add this feature and you will be able to assign the unique attribute collection to each Student record.
I have multiple user account types, each with different information. For example, business contacts link to businesses, school administrators and students link to schools. Students have physical addresses, but business contacts and school admins use the organizations address. There's other information unique to each type as well.
I'm leaning toward separate tables for students, school admins and business contacts, but using Authlogic, I have a Users table with authentication information (all need to log in).
The question is really how best to link this single authentication table with the individual profiles. It seems like a one-to-one relationship requires a single table (e.g. Users <-> Students or Users <-> Business_contacts). I want to have something of a "one-to-one-of-the-following" relationship (Users <-> Students or Business_contacts). Is there a good way to do this using a join table or other construct?
Alternatively, I could unify the common information in the Users table and come up with a "profile" column in XML to support the unique information. My thought was that keeping everything in clean DB columns would simplify selects/inserts.
Thoughts, ideas?
business contacts link to businesses, school administrators and students link to schools.
This means you have different roles of users rather than different users.
Students have physical addresses, but business contacts and school admins use the organizations address
There's other information unique to each type as well.
Which means different roles have different data and behavior, leading to different OO classes.
The question is really how best to link this single authentication table with the individual profiles.
I want to have something of a "one-to-one-of-the-following" relationship (Users <-> Students or Business_contacts). Is there a good way to do this using a join table or other construct?
The simplest model I can think of if the following:
User (Username, Email, Password, Names and other common data for every user)
Participant, abstract. (has relation to one user - defines the role of the participant, behavior and its common data). Should provide the interface for participants.
Student (inherits from Participant, adds its own behavior and data)
SchoolAdministrator (inherits from participant)
And so on
In the Object Oriented World (non RDBMS) this has a simple advantage: polymorphism. Having a user you don't need to know exactly who he is. You just do things like this:
user.participant.can_manage_stuff?
user.participant.order_book(harry_potter)
And the appropriate actions will take place which will be implemented in Student, SchoolAdministrator or other class inherited from Participant.
Another things is that it is very easy to add new roles for the system. Just inherit from Participant and implement its interface.
Now, when Object Oriented Design is done, let's have a look at the data storage. I assume you use RDBMS.
So now you have 2 types of links:
One-to-one association between User and Participant.
Generalization (inheritance) between Participant and Student, SchoolAdministrator.
Implementation of 1st is as simple as having has_one and/or belongs_to association for the following table (via participant_id column):
users:
id | username | email | password | etc | participant_id (non-null) FK_TO_participants table |
So you can easily implement that.
Now, the 2nd link can be implemented in RDBMS in number of different wasy.
But fortunately or unfortunately ActiveRecord supports only one option to do that. And it is hierarchy per table mapping strategy that uses discriminator column to distinguish the type (stored in type column by convention).
So you will have the 2nd table that looks like this:
perticipants:
id | type | student_card_number (null) | administrator_number (null) | etc
This table will have all the columns for all possible participants. This is the simplest and easiest implementation of hierarchy in DB. But not the most optimal from some points of view. As I said with ActiveRecords it is only one option available anyway.
So as a result of this design you will end up with 2 database tables (users, participants) and at least 3 classes (User, Participant, Student).
And, of course, you can vary from here a lot but that should deliver my point.
And yes, please no XML in database, don't waste your nerves and valuable personal time.
Cheers.
If you really need seperate models for each role you use, then I would recomend to use polymorphic association (read more here). So:
# User model
belongs_to :owner, :polymorphic => true
# Student model
has_one :user, :as => :owner
# Any other model
has_one :user, :as => :owner
And you need to add to users table:
t.integer :owner_id
t.string :owner_type