I have a many-to-many relationship between two models: Customers and Products. Many customers share the same database of products.
My questions is, what if I want to store Customer specific data for each product. Like how many are in stock? My first instinct is to create some kind of wrapper model (e.g. Inventory) that refers to a product but would be customer specific. Is there a better way to do this?
Glad I could be of help.
Original Answer:
Have you considered using a has many through association
Related
I'm doing a Rails project with three user types: students, teachers, and administrators. Each user type has a dozen+ columns unique to that role. Initially I thought I'd create separate models for each type, but having a single shared login seems to pose a problem (I've found a workaround on Stack Overflow, but its complex and a few years old).
What is SOP for situations like this? Is it kosher to have a single user model with 24+ columns that will always be empty depending on the role type? Or am I better off sticking with three separate models and trying to hack a workaround to make a shared login?
Thanks!
EDIT: Oops, forgot to add the third workaround which I'm favoring: having a single user model with only columns relevant to login, and then models for each role that hold columns specific to each user type. Is that a good call?
You could make two separate models, Student and Teacher. Then add an admin:boolean field for teacher. I am assuming most admins will probably be teachers? Even if that is not the case you could just default that all admins are teachers. Three separate models is terribly bulky.
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.
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