For practice I'm writing a shopping website where we have tables User and Item. A user obviously has_many items (when they are added to their basket), but the item, it belongs_to a User, even though many users will have the same item in their basket?
Furthermore, what if I want a list of items a user has added to their basket, but also a list of items they have viewed (for making suggestions based on searches), would it be better to have some 'through' tables: Basket and Viewed?
When you have this many-to-many relationships, you can use the HABTM schema:
Class User...
has_and_belongs_to_many :items
However, most of the time webshops use orderlines to keep up with items that users are purchasing. This means that an 'user' 'has_many' 'orderlines', an 'item' 'has_many' 'orderlines', an 'orderline' 'belongs_to' an 'user' and to an 'item'.
And maybe your orderlines will just be copies of items, and won't have a direct link because you don't want to alter the orderline after they have been processed. It really depends on the focus of your shop which scheme suits your needs.
Try to find some examples on the web and think about how you want to handle items, orders and baskets.
I'm used to separate things that are not the same, even if the relationship is one-to-one. So first of all I would recommend users from baskets (1:1-relationship).
After that a basket contains many items and items can be in multiple baskets (m:n-relationship). Make sure, that maybe a user likes to buy the same item multiple times.
views can be realised as a linking table between users and items: users have many views and items have many views, but one view is always linked to exactly one user and one item.
Related
I'm building a site that tracks donations and sales of items in a school auction.
Items can be sold individually or in lots, which are just groups of items bundled for sale as a single unit (like a gift certificate for a dinner Item bundled with a gift certificate for movie tickets Item).
Both of these things (Items and Lots) share fields like name, description, value. But Items have additional fields, like the donor, restrictions of use, type of item, etc.
I started by creating a table called Lot and an association table that lets Lots contain 1+ Items.
That works great for Lots. But that leaves me with a problem:
When Buyers win I need to record the win and the price. I'm doing that with a Win table that associates the Buyer with the Lot and the winning price.
But how do I deal with all the Items that aren't assigned to Lots? Should every item be in a Lot, just singly? That would make sense because it would work with the Win table scheme above, but I would need to automatically create a Lot for every Item that isn't already in another Lot. Which seems weird.
I'm sure this is a simple problem, but I can't figure it out!
Thanks!
Your approach of treating every item as a lot should be the winning one. It may sound weird, but it will make things way easier in the long run.
I have to deal on a daily base with a database where a similar problem was 'solved' the other way round, meaning keeping bundles of items and items apart and that proved to be a great pita (and for sure I'm not talking about a flat round bread here).
This database is both backbone for statistical evaluations and a bunch of (web) applications and on countless occasions I run into trouble when deciding which table to chose or how to level the differences between those two groups in querying and in coding.
So, even if your project will be rather small eventually, that is a good idea.
Yes, you need to provide a method to put every item in a lot, but this trouble is to be taken just once. On the other hand your queries wouldn't become significantly more complex because of that 'extra' table, so I'd definitely would chose this way.
It sounds like you have an Auction model that could have one or many Items. Then you could have two different types of Auctions, Auction::Single and Auction::Lot. Price would be a column on Auction. Auction has many Bids which is a join model between the Auction and the User (or Bidder). That join model would also store the bid price. When the Auction is over, you could create a separate Win record if you want, or just find the Winner through the highest Bid from Auction.
It would be helpful if you showed some code. But, what you want is a polymorphic association. So, something like:
class Item
has_one :win, as: :winnable
belongs_to :lot
end
class Lot
has_one :win, as: :winnable
has_many :items
end
class Win
belongs_to :buyer
belongs_to :winnable, polymorphic: true
end
I'm not sure whether I've accurately reflected my aim in the title, but I'll explain more here.
In my app I have Companies, and Companies has_many Key_Contacts.
Companies also has_many Sales_Opportunities.
I would like the user to be able to select some of the Key_Contacts that belong_to the Company and associate them with a specific Sales_Opportunity. I would also like the user to be able to add a Key_Contact that is not associated with any Sales_Opportunity.
The aim for this is that I can show the specific Key_Contacts that are involved in one Sales_Opportunity view on the Sales_Opportunity page, but not all of them.
Is it as simple as adding a sales_opportunity_id to the Key_Contacts model, but not setting up the "belongs_to" and "has_many" relationships? Or is there a more "official Rails" method to achieve my goal?
If I am reading this right, then all you need to do is add another has_many :key_contacts relation to your SalesOpportunity model (and belongs_to :sales_opportunity in your KeyContacts model). Then relate all contacts belonging to a specific sales opportunity.
I'm building an ecommerce Rails application, and I want to create a relationship between Products and Users.
Users can "favorite" many products (and products can be favorited by users).
Users have a "history" about the products they saw.
In SQL databases, I know I can create, for example, a History table and put the product_id and user_id. And a Favorited table with also product_id and user_id.
But in MongoDB, how can I build this relationships?
I read this blog post: http://blog.markstarkman.com/blog/2011/09/15/mongodb-many-to-many-relationship-data-modeling/ and realized that I can create an array of products inside Users collection, and an array of users inside Products collection. But I don't know how to set what is the favorited product and the history product inside Users collection.
Thanks in advance.
EDIT
Thought: I'm thinking in create two models (ProductFavorited and ProductHistory) inheriting from Product model/collection and use it inside users collection.
The best data model in MongoDB is one that fits your application use.
So the questions to ask are "When are you going to see these favorited Products? How are they displayed?" and "When are you going to see this History? How is it displayed?"
Some possible answers and advice might be:
"A user will be able to click a menu item labeled 'Favorites' and see
a list of Products that they have favorited."
Then it makes sense to store the information you plan to show in a
favorites array on the User document. Or if you expect the User
document to be growing too large, a separate favorites collection
with just a user_id as _id and then just the array of favorites as
the only other element in the document.
Or:
"A user will go to a Product page and see a list of other users that have favorited that Product."
Then it makes sense to store it the other way with all of the users that favorited the product in the Product document. Or if you think the Product document will grow too large then in a separate collection with product_id as the _id and the favorited_users as an array which is the only other element in the document.
The thing to always keep in mind is how the data will be used in your application.
Information about Data Model in MongoDB.
Hopefully we have good rails developer who can definitely give correct answer! For 2 days I didn't receive any valid answer for my question
I will explain in a very simple example
Customer is offering product. When he pushes create it gives form. Choose a category. Once he chooses another form will pop up.
Depending on a category, form should have totally different attributes.I can't have Product.new for every category. Reason is they have different attributes(Logicaly true). So do I have to create 100 models for 100 categories
Categories are : cars, apartments, coupons, books and many more
If you can give just one example I will be gratefull and call you expert
Thanks
It sounds like you're getting there. However, I wouldn't have a bunch of models like you're indicating in your question. I would say that you need a Product model and a Category model. The Category model will belong_to Product. The Product model would have many Categories. The Category model can use the acts_as_tree gem so that you can have categories and subcategories. Use javascript or jQuery (there was a recent Railscasts on this) to dynamically change and post a different field with a set of choices based on what was chosen.
EDIT:
I would have three Models; Product, Category, Specification
Product has many Categories
Product has many Specifications through Categories
Category belongs to Product
Category has many Specifications
Specification belongs to Category
This way I can create a product that has several categories. I can create several categories that have several specifications. Specifications are linked to the respective category. This will allow you to have three models and limited number of classes. Once your project is complete, new categories and specifications can be maintained by a web admin instead of a programmer.
This isn't the answer you want, but you're going to need a lot of models.
The attributes associated with an apartment (square meters, utilities, floor of building) are completely different from the attributes associated with a car (make, model, mileage, condition) which are completely different from a book (title, author, publisher, edition, etc). These items are so fundamentally different that there is no way to manage them in a single model.
That being said, there may be a core collection of attributes that might be associated with a product that is for sale (seller, price, terms). You have basically two paths forward:
You could decide to use Single Table Inheritance. In this case, you'd create an abstract class that defines the attributes that are common to all products that you are selling (seller, price, item). You'd then add a "type" column to your database that would be used to determine what type of product it is (mapped to your categories), and define all of the possible attributes in a single table.
You could choose a core set of attributes, and use these as a part of any other object that is considered a product. You'd have multiple tables that would have the full record for any given object.
Without knowing a lot of details about your application, it's hard to make a specific recommendation about which approach is right for you. Your best bet at this point is to spend a lot of time on google with "single table inheritance rails" and "multi table inheritance rails" and figure out which one is right for you (though my gut says multi table).
I've had some issues with this before when creating applications and I think I'm starting to run into it again, hence I'm asking this on StackOverflow to save me a lot of time.
I've spent the last few weeks setting up a perfected product model for my system. The model performs exactly as I want it to and has several complex features (such as search via sunspot). I wanted to setup the category to product structure before I started this heavy development - however struggling with this kind of thing was just putting me off creating the application so I got straight into the product structure.
Now I've got the product model setup - what would be the easiest way to add a category ownership to encompass the products? (All products have a category_id column which store their father category id)
My plan is to have the category index to be a list of all the categories, the category show to be a list of the products inside that category and the product show being the view of the actual product. This would eliminate the product index and so I'll have to come up with a way to port the search feature (sunspot) from my index view to the category show somehow.
As for the actual listing of the products - I assume I'll have to do some kind of partial? (I don't know a lot about it).
Most basically, my relationships are planned to be:
category:
has_many :products
product:
has_one :category
My products then have a category_id column to store the ID of it's parent category.
Any tips on how to accomplish the relationships (category show to list the products etc)?
Best Regards,
Joe
Relationships like the one you're wanting are built into ActiveRecord support. Understanding the model relationships in Rails is critical to doing anything in Rails that's non-trivial, so study up.
Also, the relationship you're looking for is something like:
product:
belongs_to :category
category:
has_many :products