I am trying to work out the best way to store my daat using mongodb and mongomapper.
I have category and each category can be described by many attributes so length in mm, weight in kg etc.
I want each user to be able to create their own attributes to descibe a category of products.
So forexample:
user A wants to store his category "cars" with number of wheels and length of car in mm
user B wants to store his category "cars" with number of wheels and length in mm and weight in kg.
The categories are the same for everyone but attributes can be different.
Should i be storing this as category collection then each cateogry contains and array of users each containing a hash of attribute anmes and units ?
Or should i be breaking this up into multiple collections somehow ?
Or is there a better way anyone can think of ?
Is it a problem with deep nesting ?
thanks alot in advancfe for help and advice.
rick
Lets start with the easy answer. Store the attributes as fields in the items document. This is why one uses a schema-less data store.
Now, about which witch attributes to put with which item. Short answer: Any of the ways you describe will work; all have some trade-offs in terms of efficiency.
I think your model goes like this:
There is a collection users
There are many collections of items called categories
each item is a member of a category
each user has many items
every item in a category has many potential attributes depending on the user
some users will share attributes
I would have the following collections: users, *categories(e.g. cars, boats, houses, etc...), attributes.
The attributes collection would list a category(e.g. cars), and attribute of items in that category (e.g. fuel mileage), and a list of user_ids who use that attribute.
Related
I am building an e-commerce app the hard way(no spree, shoppe, etc) so that I can learn rails. Currently, I have a restaurant model, meals model, and orders model. Users(using devise) can open meals, fill in an order's form with an attribute :quantity and send the order to their carts(keeping :restaurant_id, meal_id, :qty). However, meals in restaurants normally have sizes and supplementals(with cheese, with ketchup, etc.). Ideally, I would build something like spree_flexi_variants
but I just can't see how to do this... Should I nest "characteristics" and "supplementals"(becoming 2 levels deep as meals is currently nested in restaurant) in the meals, or somehow add an attribute to the meals model? Thank you guys for any suggestions!
I'm assuming that your meal object has the supplements as child items, in which case the order is also going to need child items, in this case they would be a join between supplements and order.
You don't HAVE to do it this way, it's just one possible approach. You could store the selected supplements as a serialised hash on the order row instead.
If this is a project aimed at learning, I would try both and see which feels nicest - it's all useful practice!
Within my rails app I have two models. A User model and a Book model. A user uploads and has many books.
I'm trying to add 10 predefined categories to the user model, so that a user assigns as many of the 10 categories to themselves as they wish. For example, if i'm a user that uploads a several books, and the categories I chose in my user settings are "fiction" and "science"
If another user chooses "fiction", "science", "history" as their categories, I want to be able to show them all books uploaded by users that are under these three categories including all the books I uploaded since I am under the categories of "fiction" and "science"
What is the best way to implement this? I was thinking of using the acts-as-taggable-on gem but maybe this is too heavy weight and necessary. Should I just add a string column to my user model where each category is separated by a comma, so that I can split them up into an array and do queries with Active Record?
Obviously you could create your own solution for the problem but ActsAsTaggableOn is a very good solution for it. It is not such a heavy weight as other gems.
Bonus: You can go back any time if it becomes too heavy for your application. Which I doubt.
In my e-commence app (for café/restaurants) I currently have the following database structure.
The cart is the shopping cart, in which you can add products, a temporary place before the products/an order is sent to the server. The ProductCart is a line item, many products (could be the same) with the different quantities, sizes, frying levels etc. When a order is sent, the cart is cleared and the products in the cart is transfered to the ProductOrder entity (an Order).
I now want to extend this further, with the ability of the products having ingredients and this is where it gets tricky and too complex for my head and database skills :-). As well as the (same) products can have different sizes and frying levels (hence the line item) a product should have the ability to have many different ingredients (add ons) for example a pizza, where you could choose the topping. This is what I have tried so far:
But I am not sure if this is the right structure or way to do it?
This is my suggestion.
Remove ProductOrder and Order entities. They are the same as ProductCart and Cart.
Now ProductCart should have an attribute like synchronized that is 1 or 0 based if it has been sent to server or not.
Through this you should simplify a lot your model. About Ingredient… entities they seem ok to me.
There is something fundamental you have not grasped about Core Data. Your ProductOrder entity is essentially a join table. This is completely unnecessary if you are not tracking additional attributes in this table.
Instead, you should have a many-to-many relationship between Order and Product.
It might seem that ProductCart satisfies my condition above that in this case a join table makes sense. But no - you should simply add the orders to your cart and track all the information in the Order entity.
I am building an inventory tracking tool to help people track either unique items (one-offs - say a vintage T-Shirt) or groups of items (a T-shirt design where I have a quantity). The data structures will be very similar, so that:
**Item**
Title
Status (sold, for sale) <- right now this is a simple array
Location <- this is a relationship to a diff model
etc...
**Item Group**
Title
Quantity
Status ([quantity] sold, [quantity] for sale) <- this should be an hstore??
Locations ([quantity] location1, [quantity] location2) <- not sure about this yet!
etc...
I'm expecting to use different forms to gather this information, as too much complexity on the form to accommodate these differences will add difficulty for my user group.
So my questions are as follows:
What is the best data solution for this? Do I want to have two models/controllers or try to extend the Item model? How do people usually handle this sort of issue?
I do have the requirement that I need to show the user all of their inventory (items and groups) at once, but this seems the smaller task to me.
Reduce your headaches and don't differentiate between unique items and non-unique ( ie, all items have a quantity ).
Then you want a "purchace" model, and then a "item_purchace" model to act as a join table.
Following the layout here: guides.rubyonrails.org...
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).