I wanted to make sure the design for a particular part is correct or not.
The scenario is:
A pizza can be customized by its size, toppings, crust etc. but the prize of toppings will depend on the size; like when size 7" is selected the prize for each topping will be $1 and for size 14" the prize will be $2 (or some other customization can be dependent on some other one).
One of the customization can be available only for a particular size; like when size 7" is selected then only another customization will be displayed.
(This scenario is just an example and there are many more things other than pizza which will have customization as it is a food ordering app )
Currently for this problem I've designed 3 tables:
Dishes(d_id,name,desc,base_price)
Customization(c_id,d_id(foreign key,name)
options(o_id,c_id(foreign key),parent_id,name,price)
The customization table will hold the name of customization like size, crust, toppings etc.
And the options table will hold the contents of each customization.
The parent_id in options will refer the options table because toppings price will be dependent on the size selected options.
eg:
1) dishes
id name
1 pizza
2) customization
c_id d_id name
1 1 size
2 1 toppings
3) options
o_id c_id parent_id name price
1 1 1 7" 5$
2 1 2 14" 10$
3 2 1 abc 1$
4 2 2 abc 2$
Is there any better way of representing this in the db.
Please guys revert back as soon as possible and please suggest any other changes or functionality I should include in the design(other than this part too).
It will be great if any helpful links are provided.
Thank you.
Is parent_id in options table is the foreign key of d_id in dishes table?
Related
I'm building products database where a product may have multiple variants such as Size, Color, Shape, etc. for a single product. Tricky part I have trouble with is structure of the database allowing me to link the dependencies e.g. "Red" "M" "T-shirt" or "Blue" "XS" "Trousers" which in this case are variants color and size together. I want those variants to be generic so, I'm avoiding sizes, shapes, colors tables etc. Some items may not even have any variant at all or have just one e.g. just the color.
Ideally the shape would look like so
products
id
name
1
T-shirt
2
Trousers
variants
id
name
1
Color
2
Size
variant_values
id
variant_id
name
1
1
Blue
2
1
Red
3
2
XS
4
2
S
5
2
M
product_variants
I probably don’t even need variant_id here if I provide variant_value_id which already has relationship with a specific variant.
id
product_id
variant_id
variant_value_id
1
1
1
1
The product_variants structure allows me to have "Blue T-shirt" record but how do I have those variant_value_ids work together so I could store a Blue M T-shirt or Red XS Trousers etc?
Here's my best attempt
I have inspired my model from those threads...
Modeling Product Variants
Schema design for products with multiple variants/attributes?
...but could not find an answer that would apply to my case where I could combine the variants together.
I am implementing a voting feature to allow users to vote for their favourite images. They are able to vote for only 3 images. Nothing more or less. Therefore, I am using checkboxes to do validation for it. I need to store these votes in my database.
Here is what i have so far :
|voteID | name| emailAddress| ICNo |imageID
(where imageID is a foreign key to the Images table)
I'm still learning about database systems and I feel like this isn't a good database design considering some of the fields like email address and IC Number have to be repeated.
For example,
|voteID | name| emailAddress | ICNo | imageID
1 BG email#example.com G822A28A 10
2 BG email#example.com G822A28A 11
3 BG email#example.com G822A28A 12
4 MO email2#example.com G111283Z 10
You have three "things" in your system - images, people, and votes.
An image can have multiple votes (from different people), and a person can have multiple votes (for different images).
One way to represent this in a diagram is as follows:
So you store information about a person in one place (the Person table), about Images in one place (the Images table), and Votes in one place. The "chicken feet" relationships between them show that one person can have many votes, and one image can have many votes. ("Many" meaning "more than one").
I have a column varchar(70) in one of my table where I store space separated tags:
Id Tags
1 Baby Kids Learning Alphabets
2 Kids Baby
3 Comedy Movie Fun
100 Kids Learning Alphabets
500 Kids Baby
I perform search on the column:
Get all ids where we have Baby Kids and Alphabets in the tags
I can do where Tags like '%Baby%' or Tags like '%Kids%' or Tags like '%Alphabets %'
Select query isslow when there are large # of rows. But add\delete\edit is always very fast.
So I added another table Called Tags where I store the tags alphabetically like:
Tag Id
Alphabets 1
Alphabets 100
Baby 1
Baby 2
Baby 500
Comedy 3
Kids 1
This make the searching faster, buy update\delete\insert painful.
Is my design right for future growth?
How should you design this tags column?
Thanks for reading
EDIT:
*All I am trying to pull is the list of related ids. Basically find all ids having the given tags or tag. Like on this question, you see "Related Questions" on the right. That is what I am trying to get.*
You will really have to analyze which aspects of your site will grow and what your goals are. Will there be tons of inserts? Will there be tons of tags? Do you need to answer the question "How many questions have the tag 'Alphabet'?" I hate "it depends" answers, but it really does depend on your goals and expectations.
Here is what I recommend:
Create 2 new tables. One simply stores the name of the tag
Tag Id
Alphabets 1
Baby 2
Comedy 3
Kids 4
Learning 5
Alphabets 6
The second one will link the tag to the entry in the first table
main_id tag_id
1 2
1 4
1 5
1 6
100 4
100 5
100 6
Then you can simply search with a join between the tables. It will be a LOT faster. Be sure to include the appropriate indexes.
I have 3 plans:
1, in questions table:
question
------------------------------------
id title content ... tags
------------------------------------
1 aaa bbb ... tag1,tag2,tag3 (use , to split more tags)
2, in tags table and split:
tags
------------------------------------
id tag
------------------------------------
1 tag1,tag2,tag3 (use , to split more tags)
3, in tags table:
tags
------------------------------------
id tag
------------------------------------
1 tag1
2 tag2
3 tag3
I think that plan 3 is better, but what's your opinion?
Any other good ideas for this implementation?
Thanks for the help :)
These patterns are called mysqlicious, scuttle and toxi (from the least to the most normalized).
They all have their benefits and drawbacks. You can read quite a good analysis here:
http://forge.mysql.com/wiki/TagSchema (WayBackMachine Version)
Note that mysqlicious heavily depends on your database's ability to perform FULLTEXT searches efficiently.
This means that for MySQL with InnoDB and for some other systems it's very impractical.
The relationship between tags and content is many-to-many. What this means is that one tag can be associated with several units of content, and one unit of content can be associated with several tags.
To implement this in a database, you can use an auxiliary table called ContentTags. The relationship of Content to ContentTags is one-to-many; the relationship of Tags to ContentTags is one-to-many.
#Tags Table
Id Text
1 'Tag1'
2 'Tag2'
3 'Tag3'
#Content Table
Id Content
1 "some content"
2 "other content"
3 "more content"
#ContenTags Table
ContentId TagId
1 1
1 2
2 1
2 2
2 3
3 1
As you can see, the relationship is clearly reflected (content 1 is associated with tags 1 and 2; content 2 is associated with tags 1, 2, and 3; content 3 is only associated with tag 1)
Depends on how normalized you want your data to be.
Firstly, I cringe when I see an "id" column in a table that isn't unique. At least rename the column to "question_id".
Secondly, it depends on whether you want a quick listing of all tags defined. In which, case, you'd want a separate tag table defining the set of possible tags, and then an intermediate table between questions and tags that provided a many-to-many association.
The correct approach is to create the one-many relations, that is you have one comment and multiple tags. From WIKI
In database technology, a one-to-many (also known as to-many) relationships occurs when one entity is related to many occurrences in another entity. For example, one club has many members.
And the main concept in the database design is the Database normalization.
So I'd do it like this.
comments
------------------------------------
id_comment title content
------------------------------------
12 aaa bbb
tags
------------------------------------
id_tag comment_id tag
------------------------------------
1 12 tag1
2 12 tag2
3 12 tag3
alt text http://produits-lemieux.com/database.jpg
This is basicly my database structure
one product (let say soap) will have many retail selling size
1 liter
4 liters
20 liters
In my "produit" database I will have the soap item (id #1)
In the size database i will have many size availible :
1liter
4liter
20liter
How not to duplicate the product 3 time with a different size... i like to be able to have check box in the product size of all the size available in the database and check if yes or no (boolean)
The answer a got is perfect, but how to have the option like that :
soap [x] 1 liter , [ ] 4 liter , [x] 20 liter
I'm not sure I understand your exact scenario, but to create a many-to-many relationship, you simply create a "relationship table", in which you store id's for the two records you want to link.
Example:
Products
********
ProductID (PK)
Price
Retailers
*********
RetailerID (PK)
Name
ProductRetailerRelationships
****************************
ProductID
RetailerID
A many-to-many relationship is almost always modeled using an intermediate table. For your example,
Product
--------
prod_numero
...
Size
--------
size_numero
...
Product_Size
--------
prod_numero
size_numero
...
The Size table would contain particular sizes (say, 10 liter) and the Product_Size table creates a Product and Size pairing.
You Will need an Intermediary, or "Join" Table
ProductSizes
.......................
ProductID
SizeID
One record for each product-size combination
Based on the answers, here is the database tables layout as proposed, it look complicated to me, but are you sure it is the way to do this, the BEST solution ?
alt text http://produits-lemieux.com/database2.jpg