In a rails application. If you have a User model and a post model and a user can post X number of times according to a plan.
Can I just modify the User object and add a plan_id to my user object or is it better to generate a new model called plan and associate it to a user?
It depends on what informations you want to store for the plan.
In my opinion, you should add a Plan model and add an association.
In that case, you can store all important informations about the plan itself in a Plan and use it to show them on the pricing page, as well.
But i guess, there is no "right" or "wrong" answer, just favorites. :)
There's no good way to answer this without knowing specifics or the future.
Might users end up having multiple plans?
How frequently are the plans required?
A "user" is not a "plan". A user has a plan. There should be a plan model; how it is stored is a separate issue. It may not be worth over-thinking at this point, either.
Related
In this project I am working on, there is a Course object, which has many Users and has many Assignments. Each Assignment should have a Submission for each User in the Course. Is there a preferred way to achieve this? I need it to go back and create a Submission for a User on all existing Assignments in the course if the user is added to the Course late, so I can't really just do it on Assignment creation.
Thanks!
this is basically a theoretical question.
What do you think is better for a normal rails app with users:
1)Create a Profile model where to put resume, images, links etc...
2)Put all the data in the user model.
The first choice maybe is cleaner but you have to load 2 models from the db, so maybe slower.
Thanks in advance.
I normally have a single User model. If I have unrelated resources that may deserve an associated model, than I create one for them.
For example, for me the Resume (assuming is not a single field) may deserve a dedicated Resume model, with a one-to-one association to User.
On the view, I normally create an /account resource that internally displays the account and provides the show, edit and update actions to view the account or update it.
The more models you have, the more your architecture will become complicated. So unless you have the need to split the fields out of the User model, I would keep them inside the model.
When you start to have several fields that may require a prefix, such as resume_title, resume_body, resume_created_at inside the User model, that's a good indication that you probably need a separate Resume model associated to the User.
I currently have a "user model", which is managed by the gem devise. Right now, that model has only the most basic information (first name, last name, email, password).
Now I am wondering wether I should add additional user fields as an additional, associated model (e.g. named "userprofile") or just add the additional fields to the existing "user" model (profile picture, years of experience, description about the teacher etc.). What is the common practice?
I am looking forward your help.
Best regards,
Alex
When you call current_user (or any devise helper method per se), it retrieves all the fields from the database for that user record, whether or not you need 'em. So, it's better to have as lesser fields in the devise's user model as you can. If you want to create a user profile with additional fields, better create a new associated model.
In general, add those kinds of "simple" attributes directly to the User model (i.e. years of experience, description, etc). As you add more complicated information about a user (e.g. job history), or if you have a significant amount of these attributes such that it might start impacting performance, you may want to start adding associated models. But otherwise it's probably not worth the added complexity.
Im working on an Occasion Reminder rails app where users can register then set certain future dates and holidays/occasions that the app will remind them of via email in the future... Also, they can select interests and the emails will contain relevant deals to selected interests on those dates..
Anyways, my question is pretty simple in that I am setting up the initial models for the app and am wondering if the dates/holidays and then the interests should be attributes of the User model/table or unique models of their own (setting a has_many :interests association ect ect in the user model..)
Any ideas or suggestions very welcome!
Thanks much!
I would lean toward separate models, especially for the interests. This allows you to easily query for them, and group the results to show various views of your data (e.g. find users with similar interests, or who might be going to the same event on a particular date). Separate models is also the 'correct' answer from a database normalization point of view.
It will be especially useful for your plan to offer deals based on the users' interests.
We're building an application for product support. The idea is to have multiple subdomains, each for supporting other organizations products. We call this Account - each account is tied to exactly one subdomain.
Users also have roles - but, user can have one role on account1, and other role on account2.
Basically, there are two problems:
1) many validations are based on the role current user has. Since it depends on current_account (which is session data), I cannot do these kinds of validations in the model. This leads me to some ugly controller code (ugly, in the sense that it really feels out of place). I thought of storing current_account after in the model class variable, but I read that this is not thread safe. Any recommendations?
2) almost every database record is specific to the current account; so, almost every table should have an account_id column and the model should have a belongs_to account association. I want to avoid that. The first (obvious) thing is to have a seperate database for every account, but
a) there are shared tables
b) the boss says this solution is unacceptable (there will be many accounts, with relatively low number of users). Is there a third way?
If anyone runs into similar problem:
The problem described is called multitenancy; understanding default_scope should help. Also, there is the multitenant gem which worked for me nicely.