I'm developing product card entity (postgres). All cards have similar properties (like image, description, category, price etc.) but some props are absolutely different and depend on the category to which this product belong. These different properties will be used for filters inside each category.
As example there is category 'Car wheels' and all items in it have properties like weight, diameter and brand. And when I'm inside this category I want to filter by them. There is also category 'Clothes' all items have properties size and material and when I'm inside that category I need to filter by that props.
The question is how to design these properties and entity/schema itself? Use composite type where enumerate all possible options and make them optional or?
Related
I have been asked by a customer to develop a "product configurator", and i need some inputs on how to handle the DB part of the project.
Each product can have a subset of different precreated attributes.
The minimum is 1 attribute, but there is no maximum.
Some attributes have dependencies/relationships with other attributes.
Eg. If the product is a chair, you need to choose the material (wood, plastic, metal), and you need to choose which type of legs the chair shoud have.
If the Product is a cabinet, you still need to choose a material, but instead of legs there will be different doors to choose from etc.
Each of these attributes might have subattributes. Eg. the door has a color, a size and a doorhandle.
Then the door handle has a material, a type and so on.
This ultimatly ends up in a multi-layered attribute-tree.
By itself this isnt too complicated to code, however the customer wants to be able to manage (Create, update and delete) all products, attributes and relationships between attributes, within the webapp.
So coding the relationship-part isn't a viable solution.
I have gone with a EAV model to facilitate the "potential unlimited" amount of attributes each product can have.
But i am struggling to figure out how to go about the "attribute relationships".
A simplified version of my DB design looks like this:
If each product could subscribe to groups of attributes that is legal. Then each attribute belongs to a group like "wood group".
Then the user could set the groups of attributes against a product that should need to be answered to configure a product.
With regards managing a tree, you could use a column type of hierarchyid . Or construct an outline string as key field.
An outline for example
1.
1.1.
1.1.1.
1.2.
2.
2.1.
I'm a bit confused with Sqlite, Core Data, NSUserDefaultsand PropertyList. I know what is what, but not a very clear idea of about where to appropriately use them.
I know that there are lots of tutorials, but I'm good at learning through situation based understanding. So kindly do help me to understand this in the situation that I'm facing right now and to make use of the available options wisely.
I'm working on an ECommerce iOS (native) application, where I'm highly dependent on API's for data display. Now I'm in need of recording user's review for a product and send it over through an API.
ie. I have three components, rating title, rating value(for that title) and another rating title ID. I'm defining with an example, I need to store multiple rows with details,
Components Data to be stored
**Title** - Quality | Value | Price
| |
**Rating** - 2 | 3 | 1
| |
**TitleID** - 10 | 11 | 12
Like this, there will be so many entries, i.e, the number of components differs for various users, for some users, there might be more than three components, which must be saved & send through an API. So how should I save these data? which is the RIGHT way to save these data temporarily?
If I understand you correctly, as vaibhav implied your question seems pretty general and probably relates more to structuring your data to fit your requirements than to technical aspects of the iOS / CoreData environment. In that vein, I’ll offer a few thoughts I’d have in structuring a data structure for quality ratings per your description.
If your ratings will always be for the three categories you show, i.e. Quality, Value and Price, I wouldn’t over-complicate things; I’d just use three properties in a rating record to hold the values that a user assigns in his/her rating of a product (just showing selected attributes and relationships in all following lists):
Product
name
Rating
ratedProduct (many to one)
qualityRating Int
valueRating Int
priceRating Int
Done this way you’d need to associate the values with their types in code for the APIs, such as (where item is a retrieved rating record):
display(product: item.ratedProduct.name, quality: item.qualityRating, value: item.valueRating, price: item.priceRating).
On the other hand, you may be describing a more generic approach that would allow for ratings categories that vary more frequently, or perhaps vary among products. This could apply where, for example, ratings include how well things fit for clothing but not for other products like books. In that case, you’d need a more complicated structure where a product could have a variable number of ratings of different types, so you’d need another layer of entities that let you create an arbitrary number of rating records that applied to a product.
Here you'd create a separate rating record for each rating that a user assigned to a product.
The simplest form of that structure would be like the following:
Product
name String
UserEvaluation
ratedProduct (many to one)
productRating (one to many)
ProductRating
ratingType (many to one)
value Int
RatingType
ratingTitle String
ratingID String or Int
Then you’d have to have a bit more structure where you'd list the product and then access the ratings with a loop that cycled through the set of all of the ratings linked to the product record somewhat like this (where item is a retrieved UserEvaluation):
displayTitle(product: item.ratedProduct.name)
for rating in item.productRating {
displayRating(ratingTitle: item.productRating.ratingType.title, ratingValue: item.productRating.value)
}
You'd probably want to combine these into a method that takes the name and an array of ratings.
To keep track of things, you’d also probably want to create another entity that defined product classes and specified what specialized ratings applied to each class (like fit for clothing and mileage for cars). By default, you also may want to allow for a few generic rating types that apply to all products (like the quality and price ratings you show). For this approach, the full structure would look like this:
Product Category
title
ratingType (many to many)
Product
productType (many to one)
UserEvaluation
ratedProduct (many to one)
productRating (one to many)
ProductRating
ratingType (many to one)
value Int
RatingType
ratingTitle String
ratingID String or Int
With this structure, once a product is assigned a productType, the application would know what ratings to ask for in the UI.
You could try building more complicated rating records with all of the types that apply to a product category, but that would get very messy if the applicable categories vary over time. You could also create a "custom" rating type that let a user specify a title and input a rating, in which case you'd need a text field in the rating record that only applies if the ratingType is "custom".
I hope this helps…
I'm setting up OpenERP v7. I know how to create modules and so on.
The problem is that not all the products will have the same fields. For example for T-shirts I would have Color, Size. But for belts I will have: Material, Length (as an example).
I know the option of using multi-variants but it's very very confusing. It creates a new column for Dimension values but then the Name of the product has also the Dimension values in it. It's very annoying.
Also, the access to the Product Templates is only accessible from the Sales module, so our Procurement department doesn't have access to it.
I would like more if a pre-defined template appears after a user selects the category of the product. Since products in same category will have the same field requirements.
I would suggest you the following.
Define all fields in your model (color, size, material etc.). Then hide the from views according to the product category.
To hide some field based on the category_id value you may try something like this:
<field name="some_field"
attrs="{'invisible': [('category_id', 'not in', [1, 2, 3])]}"/>
I found out a better way to solve it, which is by using the module product_custom_attributes, downloadable from: https://www.odoo.com/apps/7.0/product_custom_attributes/
This module let's me create sets of attributes that can be later loaded into the product, I can also filtrate the products depending on the attribute value which is cool.
I am working on my first Rails website, a sort of shopping website: there are products sold through the website, each with multiple unique attributes.
The use case I am imagining is: a user visits the site looking to buy a used bed, they click through several higher categories until they find a bed of the correct size, something like this:
Furniture
---> Couch
---> Dresser
---> Bed
-------> Size
----------> King
----------> Queen
...
At each time the user clicks a more narrow category, they are supplied a menu with the next level of detail (a la NewEgg). When "Furniture" is clicked, all furniture is displayed, and a menu with the types of furniture appears. When "Bed" is clicked, all beds are displayed, and a menu showing the various attributes of a bed appears, etc.
So far, I have an "Item" parent class which contains all the attributes of every item sold through the website (price, description, etc...). I am stuck with what to do next.
My first instinct is to have subclasses, but they don't seem to be that useful. There is nothing about the "Furniture" subclass that would have anything new in it, other than definiting it to be furniture. Also, each parent class needs to know about its subclasses.
What sort of design pattern should I pursue to cleanly implement this model? I've been looking into nested sets, but I am not completely sure that's the way to go. Any guidance is appreciated.
Thanks!
Your categories clearly form a tree, which is probably why you're thinking about a class inheritance tree. However, you are correct that this isn't the right model, since subclasses do not add any functionality over their parents.
You should have a single "Item" class, which is a node in the category tree - with references to its parent category (another "Item", or null for the root) and its array of children (all "Item"s).
The correct place to store the information about the tree structure is the database. In your items table, add a "parent_id" column as a foreign key - to the items table.
As the user navigates down in the tree you show the subcategories by querying for the items whose parent_id equals the current item id.
I need some advice on how to model this simple categorization (?) example:
I have a product. A product can be of different types, such as ProductType 1, ProductType 2, and ProductType 3. All products have a part number and a name. Where they differ, is the way their prices are calculated.
Products in type 1's price are dependent on how many there are of the product. So if I have 5 products, the price is $x. If I have 20 products, the price is $y, and so on.
Products in type 2’s price are dependent on each products weight. If the weight is 5 kg, the price is $x, and so on.
Products in type 3’s have a simple price, like $x for each product.
The way I see it, each “price structure” needs to have a dedicated table/class. A product will then have a reference to its price structure, dependant on the type of the product. Would you just create a “product type” table and have an attribute called Type on the Product class, or would you use generalization, so Product 1/2/3 are a subtype of Product?
There will be like 5 different price structures, and the way the price is calculated differs from each type. So the logic calculating the total price for an order is dependent on each product type.
Can you give me some advice on how to model this the best way? If I choose the approach where there’s a Type attribute on the Product class, I imagine that I will get lots of if-else statements in my code. Where if I choose to subclass them, each class can be responsible for calculating the correct price, or whatever it is asked to do.
This sounds to me like a perfect example of when to use the Strategy pattern. If you use class inheritance to define how a product is priced, you'll have to re-compile your entire system if someone later decides WidgetXYZ should now be priced by weight, instead of having a simple price.
I would define each product as having a "PricingStrategy" - in your case this would be either "volumeDiscount", "byWeight", or "simple". You could then use a Factory to provide the correct PriceCalculator object depending on the product's strategy, and that priceCalculator would calculate the product's price accordingly.
My suggestion is that in your relational data model, you will have the type column to distinguish the record type. In the code, you should definitely use sub-classing. The domain model should be independent of the underlying data model as much as possible and your description well support the need of sharing attributes (using ABC - abstract base class for Product), subtype to P1, P2, P3 (give it a meaningful domain name) and polymorphism to vary the price calculation.
Your order will hold a list of base product reference and to get the total, you will ask each product for the price and accumulate them using iterator.