Which is the best design for categorizing items? - vba

I have four levels for categorizing items according to their attributes. Some items may not require all subcategory levels and some items may share the same subcategory values.
Examples:
Category1 Category2 Category3 Category4
--------- --------- --------- ---------
Jewelry Ring Wedding
Jewelry Bracelet Serpentine
Jewelry Necklace Serpentine
Equipment Tool Power Drill
Equipment Tool Hand Jigsaw
Accessory Battery AA
Accessory Movie DVD Action
Accessory Game PS3 Combat
I want the lookup tables to contain values which are related to each item so that when users select a value from the dropdown list in the first category, the corresponding values in the next subcategory will automatically drop down (cascade), and so on.
I will predefine non-deletable, non-updatable values for most common items, however I cannot provide all possible items, for which I want to allow users to add values from the second level on down.
The objective for classifying each item is to provide a uniform method for describing items and for queries to effectively return all desired items.
Questions:
How can I make sure that new values which are added by users will link properly to parent or child values?
Should I allow users to add new categories and subcategories or should I force them to only select from pre-defined values, chose 'Other' value if their item does not fit into one of the pre-defined and enter a free-form comment?
Is the current method I have defined the best way or do you have a better suggestion?
Below are the current tables and relationships I have defined:
Columns MS-Access Informix Comments
-------------- ------------ -------- ----------------------------------------
Primary keys Autonumber SERIAL
Foreign keys Long Integer INTEGER
English Text VARCHAR Description in English language.
Spanish Text VARCHAR Description in Spanish language.
NonDelete Yes/No CHAR(1) Cant delete predefined value if TRUE.
NonUpdate Yes/No CHAR(1) Cant update predefined value if TRUE.
Deleted Yes/No CHAR(1) User-defined value cant be used anymore.
StockKeptUnit Yes/No CHAR(1) Non-serialized inventory item if TRUE.

Don't they properly link by definition? That is sort of the point of the PK/FK relationship, after all.
Presumably creation of a new tlkpItemCat2 involves selecting a valid parent tlkpItemCat1, or the INSERT would fail. As long as tlkpItemCat2.ItemCat1_SIID is defined as NOT NULL, you're pretty much assured of a valid relationship.
That doesn't guarantee that the end-user hasn't declared that a Necktie is a Power Tool, but that's a whole different problem.
Now, from experience with this exact issue (object categorisation), I can tell you that although this design looks quite elegant and useful, it is awful from a usability perspective. Your user has to know the hierarchy in advance to quickly locate the correct category for an item. And once end-users start adding levels to your hierarchy, it becomes a nightmare of back-and-forth, dead-end searches trying to locate the correct combination of Cat1/Cat2/Cat3 to apply - which leads to anything-will-do-just-to-get-past-this-screen categorisation.
A better approach is to allow the user to simply type in 'Jigsaw', and return a list along the lines:
Did you mean:
[] Equipment | Tool | Power | Jigsaw
[] Equipment | Tool | Hand | Jigsaw
[] Game | Childrens | Jigsaw
[] Accessory | DVD-Movie | Horror | Jigsaw
[] ... or [something else]?
Yes, it's more work, but from a UI and UX perspective, worthwhile.

This should allow for infinite categories. You'll need to enforce non-orphaning through your UI or OnChange events.
Then your table content would look like this:

Related

How do i continue this database? (linking characteristics with predefined values to categories)

I'm struggling to understand how i need to do this. So my problem: I'm supposed to allow someone to sell a product on a website. Before selling, he has to chose a certain category. Each category has different characteristics that could be marked, and those characteristics are entirely dependent on the chosen category. The values of those characteristics are predefined, and are already put in the database.
My question now is how do i go on about this? How do i link those characteristics to the chosen category, and how do i link the different amounts of predefined values to those specific characteristics?
example:
category: keyboard
characteristics: condition (dropdown), keyboard layout(dropdown), extra options(multiple choice)
condition has 3 options: new, as good as new, used
keyboard layout has 2 options: qwerty, azerty
extra options is multiple choice, has 3 options: gaming keyboard, wireless, 60%
second example:
category: laptop
characteristics: condition (dropdown), refresh rate(dropdown)
condition has 3 options: new, as good as new, used
refresh rate has 5 options: 50hz, 60hz, 120hz, 144hz, 240hz
Now i would have to make this work in my database, but i can't even figure it out on a relational database diagram.
Any form of help would certainly be appreciated!
I would distribute fields like this:
CATEGORIES (keyboard, laptop)
id
name
ATTRIBUTES (refresh_rate, layout)
id
name
FEATURES (50hz, 60hz, qwerty, etc)
id
attribute_id
name
CATEGORIES_ATTRIBUTES
id
category_id
attribute_id
PRODUCTS
id
name
category_id
condition (could be an enum, I put it here as every product has a condition)
PRODUCT_FEATURES
product_id
attribute_id (redundant but it can save you a join when making queries)
feature_id
Cheers!

Data Type Qualifiers Definition PostgreSQL

How would I go about defining a table with a language specific (qualified) attribute?
For example:
ID| object |description (english)|description (french)| size | color (english) | color (french)
in the above example we have 3 'normal' fields and 2 language qualified fields : description and color.
What is best practice for defining these type of fields within one table?
There are different ways of doing this. But a method for your specific data is to have another table with one row per language. Such as table would have:
objectLanguageId (serial column to identify the row)
objectId (reference to a table with one row per object)
language
description
color
Then the "object" table would have
objectId
objectName
size
Note: This is definitely not the only approach. If you need everything in your system translated, then you want a more sophisticated and generic mechanism. You may also need to take into account things like French sizes are different from sizes in other countries -- even countries that speak the same language.

Most appropriate way to store/retrieve User Input in a eCommerce iOS application?

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…

How to differentiate products depending on attributes in a Point of Sale Database Schema

Here is my dilemma, I am building a POS system for a pretty large retailer, they have different products which have different attributes (size, color, etc...).
When they receive the merchandise from the supplier they want to do their own labeling with their own UPC Bar Codes but they also want to differentiate between the different sizes using the code on the article.
Say they received Brand A shirts with 4 sizes S,M,L,XL then they should have different bar codes for each size.
So I thought of having a base code for the article and then concatenating numbers depending on the attributes to have different codes? and if no attributes are available just add 0s
I am storing the sizes and colors as attributes in the database as an (Entity-Attribute-Value). Is their a better way other than having to start concatenating numbers from the attributes to come up with the full code?
Thanks for your help!
edit-------------------------------------------------------
I am making the example a bit clearer
so the base code for the shirts is: 9 123456
Then for Color blue is: 789
and then for size S: 012
so the full code is 9 123456 789012
for another article that doesn't have size or color or actually any attribute
the base code would be 9 654321
plus 000000 for the attributes part
this is just for simplicity sake as I can use only one digit per attribute.
The other issue is when linking to the OrderDetails table I need to reference all the attributes to know that the customer actually bought Size S in Blue
One possible option is to create a table that stores the bar code as the key. Then have an attribute for the size and the color.
Actually #jzd your answer is pretty close but I would like to keep the attributes as key value pair.
The idea is to use and an attribute set and have a bar code associated with each set. here is a rough schema
AttributeSet Table:
AttributeSetId
ProductId
AttributeSetName
BarCode
AttributeUse Table:
AttributeSetId
AttributeId
AttributeSetInstance Table:
AttributeSetId
AttributeId
AttributeValueId
if you forget the barcode for a minute...
do you have a database to track this inventory?
are the items stored discretely in this database?
if so, then just add a unique number to the item, called the UPC vale - i recommend not trying to make an intelligent key s\as you are describing

Search products with parent and child categories

I'm building a shopping cart website and using SQL tables
CATEGORY
Id int,
Parent_Id,
Description varchar(100)
Data:
1 0 Electronics
2 0 Furniture
3 1 TVs
4 3 LCD
5 4 40 inches
6 4 42 inches
PRODUCTS
Id int,
Category_Id int
Description...
Data:
1 5 New Samsung 40in LCD TV
2 6 Sony 42in LCD TV
As you can see I only have one column for the last Child Category
Now what I need to do is search by Main Category at homepage, for example if the user clicks to Electronics, show both TVs as they have a Parent-Parent-Parent Id at Electronics, keeping in mind that Products table do have only one column for Category.
Shall I update the Products Table and include 6 columns for category childs in order to solve this? Or how can I build an effective SQL Stored Procedure for this?
Thank you
Jerry
in Oracle, you would use CONNECT BY
If you're using SQL 2008 then you might want to look at the HIERARCHYID data type. Otherwise, you might want to consider redesigning the Category table. How you have it modeled now, you have to use recursion to get from children notes to parents or from parents down through children.
Instead of using the linked list model (which is what you have) you could use the nested set model for hierarchies. Do a search on Joe Celko and Nested Set Model and you should be able to find some good descriptions of it. He also wrote an entire book on modeling trees and hierarchies in SQL. The nested set model requires a bit of set up to maintain the data, but it's much easier to work with when selecting out data. Since your categories will probably remain relatively stable it seems like a good solution.
EDIT: To actually answer your question... you could write a stored procedure that sits in a WHILE loop, selecting children and collecting any products found in a table variable. Check ##ROWCOUNT in each loop and if it's 0 then you've gotten to the end. Then you just select out from your table variable. It's a recursive (and slow) method, which is why this type of a model doesn't work very well in many cases in SQL.
Under almost no circumstances should you just add 6 (or 7 or 8) category IDs to your products table. Bad. Bad. Bad. It will be a maintenance nightmare among other things (what happens when your categories go 7 levels deep... then 8... then 9.
Use recursive CTEs to do this ! works like a dream ! http://msdn.microsoft.com/en-us/library/ms186243.aspx