I am designing database for jewellery website in which a lot of products will store. While designing tables for attributes of products i stuck. My problem is how store product attributes and there sub attributes and so on in database.
Up to now i have created 3 tables for product and attributes -
tbl_attribute
Structure: attribute_id*, attribute_name
tbl_products
Structure: product_id*, category_id(FK), product_name, seo, description, metatags, length, width, height, weight, image, status
tbl_products_attribute
Structure: product_id(fk), attribute_id(fk), value
I have a situation suppose Necklace have 5 stones (Stone is attribute) and each stones have following sub attributes
1. Stone Name
2. Stone Color
3. Stone Treated Method
4. Stone Clearity
5. Stone Shape
6. Stone Price
and so on etc.... and i have So many attributes like stone so can you please help me how to design the table for these attributes.
Depends on that attributes i have to search(FILTER || Faceted Search) the products in front end.
Like: www.firemountaingems.com
Detailed attributes and sub attributes list:
Alphabatical
Availability (Sold Individualy, Sold in Bulk)
Birth Stone
Brands
Color (red, green, blue)
Design Type
Gender (Male, Female)
Images
Karat (18k, 22k, 24k)
Link
Make (Hand, Machine, Oxidised)
Making Percent
Material Type (Leather, Gemstone, etc)
Metal Art
Metal Stamp
Metal Type (Gold, Silver, PLatinum etc)
Model
Name
Price
Purity
Shapes (round, oval, emerald, diamond etc)
Short Description
Sides (single, both,)
Size (small, big etc)
Special Price
Status
Stone (Name, Color, Treated Method, Clearity, Shape, Price, Main Stone Color (Red, Pink, Green))
Stringing Material
Warranty
Wastage Percent
Weight
Wire - Wrapping Wire
Up to now i have search so many tutorials and article on net as well as on stack overflow.
Your help is highly appreciated.
In this case you cant afford creating tables like this the best approach is to have only 1 product table and 1 attributes table which will be having all attributes of a product but with columns attribute_level and parent_id where parent_id refers id of same table.
Example:
products table:
ID | Name
----------
1 | Necklace
ID | ParentID | AttributeName | ProductID | AttributeLevel | AttributeDescription
----------------------------------------------------------------------------------
1 | | Stone | 1 | 1 | stone description in general
2 | 1 | StoneName | 1 | 2 | Ruby
In this way you can make hirerchy of attribute levels within one table.
Related
I have a teacher who doesn't like to explain to the class but loves putting up review questions for upcoming tests. Can anyone explain the image above? My main concern in the red underline which shows that supplier and supplierPhone are repeated values. I thought that repeated values occurred when there were many occurrences of the same item in a column.
Another question I have is that if the Supplier is a repeating value, why isnt Part_Name a repeating value because they both have 2 items with same names in their columns.
Example:
It's repeated because the result of the tuple is always the same. E.g. ABC Plastics will always have the same phone number, therefore having 2 rows with ABC Plastics means that we have redundant information in the phone number.
Part1 Company1 12341234
Part2 Company1 12341234
We could represent the same information with:
Part1 Company1
Part2 Company1
And
Company1 12341234.
Therefore having two rows with the same phone number is redundant.
This should answer your second question as well.
Essentially you're looking for tuples such that given the tuple (X, Y) exists, if there exists another tuple (X, Y') then Y' = Y
Looks like five tables to me.
model (entity)
modelid description price
1 Laserjet 423.56
1 256 Colour 89.99
part (entity)
partid name
PF123 Paper Spool
LC423 Laserjet cartridge
MT123 Power supply
etc
bill_of_materials (many to many relationship model >--< part )
modelid partid qty
1 PF123 2
1 LC423 4
1 MT123 1
2 MT123 2
supplier (entity)
supplier_id phone name
1 416-234-2342 ABC Plastics
2 905.. Jetson Carbons
3 767... ACME Power Supply
etc.
part_supplier (many to many relationship part >--< supplier )
part_id supplier_id
PF123 1
LC423 2
MT123 3
etc.
You have one row in model, part, supplier for each distinct entity
You have rows in bill_of_materials for each part that goes into each model.
You have a row in part_supplier for each supplier that can furnish each part. Notice that more than one part can come from one supplier, and more than one supplier can furnish each part. That's a many-to-many relationship.
The trick: Figure out what physical things you have in your application domain. Then make a table for each one. Then figure out how they relate to each other (that's what makes it relational.)
I have an assignment for shopping cart dealing with shirt store, and was confusing with database design in storing shirt attributes such as color, size and stock for each item.
Let's say to store below shirt to db:
Product name: Nike shirt
Available colors: black, white, blue
Size: M, L, XL
Stock: Black - M - 5 pc
White - L - 10 pc
Blue - M - 2 pc
Blue - XL - 3 pc
(and so on...)
Instead of storing above info iteratively in a table like so:
table shirt
id product color size stock
---------------------------------------------
1 Nike Shirt black M 5
2 Nike Shirt white L 10
3 Nike Shirt blue M 2
4 Nike Shirt blue XL 3
....
What is the best way to design table to keep these attribute and product effectively?
I know that could be JOIN multiple table together, but I need advise on these attributes on how to put separately with difference table and fetch the info when people goes to respective page and show them up how many stock are left for the specific size?
Here's your table.
Shirt
id product color size stock
---------------------------------------------
1 Nike Shirt black M 5
2 Nike Shirt white L 10
3 Nike Shirt blue M 2
4 Nike Shirt blue XL 3
....
You see how you've duplicated the product name "Nike Shirt" and the color "blue". In a normalized relational database, we don't want to duplicate any information. What do you think would happen if someone accidently changed "Nike Shirt" to "Nike Skirt" in row 4?
So, let's normalize your table.
We'll start with a Product table.
Product
id product
------ ------------
0 Nike Shirt
Generally, database id numbers start with zero, not one.
Next, let's create a Color table.
Color
id color
------ -------
0 black
1 white
2 blue
Next, let's create a Size table.
Size
id size
------ -----
0 XS
1 S
2 M
3 L
4 XL
5 XXL
Ok, now we have 3 separate object tables. How do we put them together so we can see what's in stock?
You had the right idea with your original table.
Stock
id product color size stock
---------------------------------------------
0 0 0 2 5
1 0 1 3 10
2 0 2 2 2
3 0 2 4 3
The product, color, and size numbers are foreign keys back to the Product, Color, and Size tables. The reason we do this is to eliminate duplication of the information. You can see that any piece of information is stored in one place and one place only.
The id isn't necessary on the Stock table. The product, color, and size should be unique, so those 3 fields could make a compound key to the Stock table.
In an actual retail store, a product could have many different attributes. The attributes would probably be stored in a key/value table. For your simple table, we can break the table up into normalized relational tables.
Substituting surrogate keys for text identifiers isn't normalizing. The original functional dependency (product, color, size) -> stock remains unchanged in your final version, and is in fact fully normalized. – reaanb Jul 31 '15 at 21:33
This is a horrendously complicated business domain. Your suggested single-table layout has a couple of challenges. Firstly, lots of repeated entries are a smell in database design. Secondly, it kind supposes that all entities have the same attributes - as #gilbertleblanc writes, there are likely going to be lots of other attributes a real-world application would need to store (manufacturer, material, allergy info, etc.).
So, I would split this into two questions:
Which products and variants exist?
How much stock do we have of each item?
The minimal way to represent your sample data would be:
products
----------
id
name
color
size
product_stock
------------
product_id
stock_quantity
In real-life scenarios, the stock table is usually a ledger of transactions - the sum of movement gives you the current amount in stock.
product_id date movement
---------------------------------
1 1 Jan 2021 10
1 2 Jan 2021. -1
1 3 Jam 2021. -4
I need to implement a tagging system which is something like this :-
Every user can be tagged on the basis of his education. ( Tags be : Primary, secondary, High School) and these Tags fall under the umbrella of "education".Similarly the user may also be tagged on his interest(Cricket, Football, Rock music, pop music...) Cricket and football come under "Sports", rock music and pop music come under "Music".
Current design is :
User Userid TagID TagName UserId TagID
=========== ============= ============
1 User1 1 Pop 1 1
2 user2 2 Rock 1 2
3 Techno 1 5
4 Cricket 1 6
5 Football 2 1
6 Primary Scl. 2 4
7 Secondary scl 2 7
These 3 form the major tables that allow many to many relationship between users and tags.
secondary tables are:
(Music) (Sports) (Education)
TagID MusicID MusicType TagID SportID Sport TagID EducationID Education
======================= ==================== ============================
1 1 Pop Music 4 1 Cricket 6 1 Primary
2 2 Rock Music 5 2 Football 7 2 Secondary
3 3 Techno Music
the problem in this structure is that a TagID from table TagTable can be referenced by both Music and Sports if care is not taken.There is a chance that pop music and cricket will refer to the same TagID if the developer doesn't take necessary care.
How do I avoid this possibility of multiple referencing ?
Note : The secondary tables have been used to check if the tags fall under the same umbrella. This is feature of grouping tags is necessary.
Looks like you need something similar to this:
NOTE: Tag names are globally unique in the model above. If you need to make them unique per category, just include TAG_CATEGORY_ID in the UNIQUE constraint TAG.U1.
BTW, do you need to limit user to only one tag from certain categories? For example, can user have both Primary and Secondary tags from the Education category, or not? If you need to limit this, you'll need to reference such tags in a different way (as opposed to the "simple" junction table USER_TAG) and there will be certain complications to prevent mixing "single" and "multi" tags...
I am trying to store a family tree.
Here is the platform that I am using, Zend framework, Mysql, Ajax
I have searched stackoverflow I came across this post which is very helpful in handling data in terms of objects.
"Family Tree" Data Structure
I'll Illustrate my use case in brief.
User can create family members or friends based on few relations defined in database. I have Model for relations too. User can create family members like Divorced spouse, frineds. Max the Tree can be deep that we are assuming max to kids of the grandchildren but it can expand in width too. Brother/sister & their family.
I am looking an efficient database design for lesser query time. If I have to use the data structures described in above post where I must keep them as they necessary have to be a Model.
For representation I am planning to use Visualization: Organizational Chart from
http://code.google.com/apis/chart/interactive/docs/gallery/orgchart.html#Example
I'll summarize what I need
Database design
Placing of controllers (ajax) & models
The people that the user will create they will not be any other users. just some another data
yeah thats it! I'll post a complete solution on this thread when I'll be completing the project, of course with help of expertise of u guys
Thanks in advance
EDIT I I'll Contribute more to elaborate my situation
I have a user table, a relation table, & last family/family tree table
the Family table must have similar structure to following
ID userid relation id Name
1 34 3 // for son ABC
2 34 4 // for Wife XYZ
3 34 3 // for Mom PQR
4 34 3 // for DAd THE
5 34 3 // for Daughter GHI
6 34 3 // for Brother KLM
The drawback for this approach is generating relations to the other nodes like daughter-in-law, wifes brother & their family.
The ideal way of doing is for a user we can add Parents, siblings, children & for extra relations they must be derived from the family members relation i.e. Brother-in-law must be derived as sister's husband, or wife's brother.
THis is what I can think now. I just need Implementation guidelines.
Hope this helps u guys to provide a better solution.
I guess that from the database point of view it would be best to implement it like
id | name | parent_male | parent_female
Other option would be string prefixing
id | name | prefix
1 | Joe | 0001
2 | Jack | 000100001 //ie. Joes son
3 | Marry| 0001 //ie. Jacks mother
4 | Eve | 0002 // new family tree
5 | Adam | 00020001 // ie. Eves son
6 | Mark | 000200010001 // ie. Adams son
Other (more effective) algorithms like MPTT assume that the data is a tree, which in this case is not (it has circles).
To show it would work - to select Mark's grandparents:
--Mark
SELECT prefix FROM family_tree WHERE id = 6;
-- create substring - trim N 4-character groups from the end where N is N-th parent generation => 2 for grandparent ==> 0002
--grandparents
SELECT * FROM family_tree WHERE prefix = '0002'
-- same for other side of family
-- cousins from one side of family
SELECT * FROM family_tree WHERE prefix LIKE '0002%' AND LENGTH(prefix) = 12
I am considering how to structure my MySQL database in e-commerce solution. To be more specific I am looking at the product structure.
These are the tables I have come up with so far. What do you think?
Explanation of structure
The application is multilingual. Therefore the product table are split in 2 tables.
If a products has e.g. 2 variants (Small, Medium) a total of 3 rows will be inserted. This is because each variant can have different information for each variant. When the product is shown on the webpage product 1 will be shown with a drop down box with Small & Medium. A product with no variants will naturally only insert 1 row.
products
id master product_number
1 0 123
2 1 456
3 1 678
products_descriptions
id product_id country_code image name description vat price
1 1 en-us image.jpg t-shirt Nice t-shirt 25 19.99
2 2 en-us image.jpg t-shirt Nice t-shirt 25 19.99
3 3 en-us image.jpg t-shirt Nice t-shirt 25 19.99
products_to_options
product_id option_id
2 1
3 2
options
id name
1 Small
2 Medium
Your Products table is schizophrenic, its entity is sometimes Product and sometimes Variant. This leads to very cumbersome behavior. For example, you'd like the question "how many different products do we have?" be answered by select count(*) from products, but here this gives the wrong answer, to get the correct answer you have to know the Magic Number 0 and query select count (*) from products where master=0. "List all products and how many variants we have for each" is another query that should be straightforward but now isn't. There are other anomalies, like the fact that the first line in products_descriptions is a shirt that has a price and a picture but no size (size is stored in the variants, but they have prices and pictures of their own).
Your problem sounds like you have products in two contexts: (1) something that can be displayed as an item in your store, and (2) something that can be ordered by your customer. (1) probably has a name like "Halloween T-Shirt" or so, and it probably has an image that the customer sees. (2) is what the customer orders, so it has a (1), but also a variant specification like "small" or maybe a color "red". It probably has a price, too, and an order_id so your shop can know what specific item to ship.
You should give each context an entity. Here's how i'd do it
displayable_product
id name
1 "Baseball Cap"
2 "T-Shirt"
orderable_product
id d_product_id order_id size color price
1 1 123 red 9.99
2 2 456 small 19.99
3 2 789 medium 21.99
displayable_content
id d_product_id locale name image
1 1 en_US "Baseball Cap" baseballcap.jpg
2 1 es_US "Gorra de Beisbol" baseballcap.jpg
3 2 en_US "Nice T-Shirt" nicetshirt.jpg
4 2 es_US "Camiseta" nicetshirt.jpg
You should probably use locale instead of country in the display tables to account for countries with more than one language (USA, Switzerland, and others), and you might separate the size and color into its own variants table. And if you need country-dependent data on the orderables (like different prices/currencies for shipping to different countries), you'd have to extract a country-dependent orderable_content table, too.