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
Related
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!
What are reference field and reference table, why we need to specify for currency and quantity fields, where we can check the reference field/reference tables for our requirement?
I am creating a smart form for purchase order item data so, I need quantity and price fields, so what fields I have to take and what reference fields I have to specify?
Your reference field should be the the field containing the relevant currency or unit for the amount in your field. This can be within the same table or in another table (see SAP Help for technical details).
It's easy to understand if you use an example. Your SmartForm may contain an offer with the following text: "The price of 5 paper is 2." That won't help much, because the recipient would be wondering: Is it 5 sheets of paper, 5 boxes of paper, 5 kilograms of paper? And do I pay in Euros, US-Dollars or Bitcoins?
That's why you need a reference field, containing the unit and/or the currency. The amounts does not make any sense on it's own or may cause problems if someone starts adding them up under wrong assumptions etc.
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 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:
I am interested in the implementation of the search engine in autoscout24.de. It is a platform where you can sell/buy cars. Every car advert has properties: make, price, kilometers, color, etc. (in sum over 50 different properties) that can be searched for.
I am specifically interested in the detail search that works like this: every possible property is displayed on the page. In brackets behind each property there is the number of cars that will match the new search if the property is selected.
Example: I'll start with empty search criterias.
Property make:
BMW (100.000)
Volkswagen (200.000)
Ford (150.000)
...
Property color:
black (210.000)
silver (50.000)
white (100.000)
...
and so on for the other properties.
I'd like to know:
How would you implement this kind of search with SQL?
How would you implement it with an in-memory data structure?
Range queries should be supported, too (all cars with price from X to Y)
Update:
The numbers in brackets show the number of results after the addition of the search criteria. So it changes each time a property is added / removed...
So a naive algorithm would work like this:
find all cars with current search criteria (e.g. make Ford)
for each property do: find all cars that matches previous search criteria ("Ford") AND the search criteria for the chosen property. Write the count in brackets behind the property.
This algorithm is naive because it would execute 1 + N queries (N=#properties). Nobody wants to do that ;-)
I believe that this is referred to as "faceted search". The Apache Solr project might be worth looking at.
It's a basic code
Create a result object with one counter for each property that the cars have
Check all cars one by one, if the car match the filter then add one to each of the numbers
...But it's blasting fast !
I think they do it on several computers, shreading data across them. Each computer compute 5% of the data and send the result to the front computer wich sum all counts.
There are tools for that : look for "map reduce", "elastic search", "strom"...
Have a properties table:
+Properties
id
title
value
count
The count field allows you to "earn" an extra query , so instead of checking how much cars have a certain property , you can just update this field when adding new cars.
Example of rows in this table:
1 'color' 'white' 1000
2 'color' 'black' 122
3 'km' '5000' 1233
4 'km' '30000' 54
And for the cars table , for each property add a field.
+Cars
id
color
km
and the color and km fields will hold the ID's of the property's row in the Properies table.
EDIT: if you're planning not to use mysql db , you might consider using XML files to contain the properties data. But once again, you should update its count value anytime you add / remove or update a car.
<Properties>
<Property>
<Type>Color</Type>
<Value>White</Value>
<Count>1000</Count>
</Property>
</Properties>