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.
Related
I have seen regular debates about the way to manage the different class of users.
Usually, it seems that developers prefer a role based approach (e.g. user, admin,...) with gems like Cancancan
But I'm wondering if it's applicable for an appointment booking app (appointment for doctors, teachers,... or even bookings). Indeed in this case, the 2 types of users have access to totally different pages. In its documentation about associations, Ruby on Rails guide takes the example of a medical appointment booking app with 1 table for doctors and 1 table for patients.
For this kind of app, I'm a little bit lost regarding the most efficient solution!
Thanks!
You can use a tool like Cancanan to break out the different roles and abilities, then restrict access to certain parts of the system based on those rules.
Additionally you can display only the relevant navigation or pages when the user's accessing the system so they might not even be aware of what they're not seeing.
Question
I have a User model with authorisation and authentication logic built.
Now I realise I have three different types of users. I want to store different information about each of them.
What is the best way to handle this in Rails?
Thoughts based on current reading
I've looked at STI but from what I've read feel it is inappropriate because I'll end up with a lot of NULL fields in my database.
Ideally I'd like to not duplicate the authentication / authorisation logic for each of the three user types.
Each user will also have different functionality within the application.
You can try using polymorphic associations and creating table users with data that all types of users have and putting other data in seperate tables. Railscast epizode covering this topic.
There are lots of ways to do this. Here's one approach:
Instead of thinking of different types of users, you could think of roles that a user has.
For example, if a user could be a butcher, baker, or candlestick maker, you could have four tables: users, butchers, bakers, candlestick_makers. The latter three role tables each have a user_id column; they "belong to" the user.
If you need to enforce that a particular user has only one role, you will have to do that in the application (since this database schema would allow multiple roles for a single user).
This method is good if there is a lot of stuff that would belong in those role tables. If not, leaving some NULL columns on the users table probably won't kill you.
I am setting up a simple has_many through relationship. I was wondering if there are any best practices I should consider when setting up the foreign key relationships.
The application is designed to allow users to create items and ads, where a listing model is used to connect items with ads (the listing model also has timestamps and an order field).
The main question I have is: which models should belong_to the user model? I was thinking that the simplest solution is to have listing belong_to user. That way I can use the has_many through relationship to figure out which items and which ads belong_to each user.
However, it occurred to me that this could leave some holes depending on what work-flows I want to make possible. For example, what if a user wants to create a bunch of items before creating an ad which has those items? What if a user creates an ad before having created any items?
Based on the above, I was thinking that maybe I should just make ads and items belong to user. If I do that, is there any obvious reason to also make listing belong_to user? I was going to do that, but somehow it just looked redundant to me.
This seems like a pretty typical situation to encounter in a rails app, so I was hoping somebody with experience has been here and might be able to share some insight.
Thanks!
I'm trying to understand what you have:
User
Ad
Item
Listing
Where Listing appears to be some kind of join model that relates an Item to being in an Ad.
I don't see much of a wrong way to do this. I suppose the most normalized way of doing this would be to just have an Item belong_to a User, and get the Listings and Ads through that. But you'd be paying a price there too, both in having to write annoying code and having to perform multiple joins to get your Ads.
The opposite extreme is just to have everything belong_to the user. You have an extra column in 2 of your models, but then you also have much simpler relationships. You also wouldn't have to worry about what workflows your users are allowed when designing your schema.
Even if you mess up and leave out user_id fields in your models, it isn't terribly hard to add those fields later using migrations.
I'm building a Rails app that has Etsy.com style functionality. In other words, it's like a mall. There are many buyers and many sellers.
I'm torn about how to model the sellers. Key facts:
There won't be many sellers. Perhaps less than 20 sellers in total.
There will be many buyers. Hopefully many thousands :)
I already have a standard user model in place with account creation and roles.
I've created a 'role' of 'seller', which the admin will manually apply to the proper users. Since we'll have very few sellers, this is not an issue.
I'm considering two approaches:
(1) Create a 'store' model, which will contain all the relevant store information. Products would :belong_to :store, rather than belonging to the seller. The relationship between the user and store models would be: user :has_one store. My main problem with this is that I've always found has_one associations to be a little funky, and I usually try to avoid them. The app is fairly complex, and I'm worried about running into a cascade of problems connected to the has_one association as I get further along into development.
(2) Simply include the relevant 'store' information as part of the user model. But in this case, the store-related db columns would only apply to a very small percentage of users since very few users will also be sellers. I'm not sure if this is a valid concern or not.
It's very possible that I'm thinking about this incorrectly. I appreciate any thoughts.
Thanks.
I would definitely use a relationship between a store and a user. This provides a lot more flexibility and is a much cleaner data design.
I have never had any issues using any of the basic associations in Rails/Active Record.
What do you mean by "funky"?
Consider a typical social networking website, which has more or less the following models:
User
Blog, Posts
Forums, Topics, Responses
Wiki, Pages
....
....
I want to introduce a model called Site/Space where each User can have one or many sites/spaces. And I want to provide a way for the Site owner to select many features (or call it apps/tools).
Whats the best way to design this model - so called feature/app/tool?
Note: In many cases each feature may not be the same as corresponding model. Lets consider blog feature, by enabling the Blog feature, I should be able to associate (some how) that the corresponding site has access to both Blog & Post, (another example) by enabling Forums feature, I should be able to associate the site has access to not only Forum, but also Topic & Response models. I need these checks so that I could define a before_filter to check if a particular site has access to the content or not.
I looked at some open source rails applications that have this kind of on demand features, but by looking at the form attributes, it looks like they have has_blog, has_post,... fields tucked in the Sites table, in my situation it may not work as the number of these models may grow. Do you still think that adding these boolean fields in the Sites table is the best approach?
polymorphic associations, has_many :through, and/or has_and_belongs_to_many sound like the building blocks to your solution. I'd look into them.
Define a many-to-many relationship between an Apps and a Sites table in your database.
Apps
AppID
Name
...
Sites
SiteID
UserID
...
SiteApps
SiteID
AppID
SELECT AppID FROM SiteApps WHERE SiteID=...
See also SQL: Many-To-Many table AND query