I have two tables : products and tags.
products
key | name | description | url
tags
key2 | tag | tag description
Association
One tag can be associated with many products.
each product has one or more tags associated with it.
eg a product "plate" has the tags "ceramic", "white", "delicate", etc associated with it.
I don't know however how to create a many-to-many representation.
What's the best way to store these tag associations? Create a tags field in products? Or another table? Thanks!
Edit: tags are many-to-many, thanks S.Lott
One tag can be associated with many products and each product has one or more tags associated with it.
That's not a one-to-many. That's many-to-many.
Google "Association Table" or "Junction Table" for numerous examples.
http://en.wikipedia.org/wiki/Junction_table
http://www.youtube.com/watch?v=P_nhBKs25DQ
I would go with an additional table named (productTags: key, productKey, tagKey) that would map the two tables together.
Related
I am totally confused to store category and product data stored in the same table in hierarchical relation/Parent-child relation use in a table or if we create two separate table for category and product table?
in above table, i used the same table for storing category and product with parentId and childId, If we use like this then what benefits? Or we use a separate table for category and product and why? Please anyone help me
This really depends on if the relationship between store and product categories are one to many or many to many and if a single category can only belong to one category tree.
If the relationship is one to many, and a category can only belong to one tree, then you'll be able to use a single table, with a foreign key referencing the same table.
Otherwise, you'll likely be looking 2 or 3 tables. At a minimum you'll need one table for your categories, and then another for you relationship (what's known as a composite key table).
Also, if Product categories and Store Categories are inherently different (hold different data) then you should be using separate tables for them anyway.
I have a Product and a Product Category.
I can define a Product has Product Category relationship, or Product Category has Product.
Both make sense to me. My aim is to achieve a grouping of products to categorize them more easily. I see Product Category as a helper concept and not a concrete concept. i.e. a Product is something I could sell, something I can place into a shopping cart, etc. I cannot do that with a Product Category. But I can use it to group things, i.e. show a listing of Productthat belongs to a certain Product Category.
Many to Many relation is symmetrical, I assume, and there are two ways to create it. How can I determine which direction is correct in my case? Is there one?
Since many-to-many is bidirectional, there really is no need for consideration of a "correct direction". As for the design, I would create product_category as a static table with only primary keys; the products table with its own primary key column(s) such as Product ID; and a third association table which foreign keys the primary keys from the two tables.
PRODUCT_TAGS
PROD_ID|CAT
21|Heating
21|Security
25|Heating
37|Lighting
37|Security
I think you have a one-to-many relationship instead of a many-to-many.
Whenever I look at relationships of any type, I ask myself a question about the tables (using your table names):
Does a product have many categories, or does a category have many products?
If the first point is true, then the ID from the product table goes into the category table. Otherwise, the ID from the category table goes into the product table.
If both is true (a product has many categories and a category has many products), then you'll need a joining table.
I'm assuming that a category has many products, but a product can only have one category. If that's true, you would add a category_id to your product table.
If it's a many-to-many relationship, your table would look like this:
product_category_map (product_id, category_id)
Hope that answers your question. I recently wrote an article on normalisation that covers the concept of one-to-many and many-to-many relationships as it can be a confusing concept. (Disclosure: I own that website).
I have a database that contains two tables:
entries
tags
The entries table contains posts that each have one or more tags. The problem is, each post can have any number of tags. In other words, I can't have a 'tag1', 'tag2', etc. column and do a LEFT JOIN.
How should I set up entries so that each post can have any number of tags?
You need a mapping table.
Create a table called entries_tags that contains two columns: entry_id and tag_id, with a multi-key on both entries.
This is called a many-to-many relationship.
You can also do it the SO-way, where in addition to having a junction/mapping/intersection table, you have a list of tags on the entry that's taggable:
entries table:
post_id: 3539744, .... tags: sql, database, database-design, tags, data-modeling
If you can't take the performance hit of using a junction table when pulling the associated tags for an entry. Of course extra care has to be taken here because you are dealing with denormalized data.
How would I represent the following in a CakePHP model?
Product
=======
product_id
....
Cart
====
cart_id
....
Carts_Products
==============
cart_id
product_id
quantity
Since you are storing data in your join table (for a HABTM relation), you're situation looks quite similar to Rail's 'through' relation (seen at the bottom of this diagram). As such, you will want to create a model for that table and use Cake's 'with' relation setting seen on the HABTM page of the book. You should then be able to access the data stored on the join table. By convention...
your tables should be named products, carts, carts_products
your models should be named Product, Cart, CartsProduct
I would also add that (for CakePHP2) the column names for product and cart need to change.
products
========
id
name
...
carts
=====
id
create_date
...
I believe the answer to your question will be revealed on careful reading of this documentation page.
I am creating an online blog website and for each blog post, I'd like to have the user be able to create/edit/delete their own category so that they may categorize their post.
What is generally considered a good database design for user generated categories?
This is my proposed table design. (Is there a name for this type of db?)
USER_TABLE
user_id (pk), user_name
CATEGORY_TABLE
category_id (pk), category_name
USER_CATEGORIES
user_id (fk), category_id (fk)
Thanks for helping out. I'm confident there's a post somewhere regarding this but I was unable to find it. If this is a dupe please let me know and I will remove this question.
This is a many to many relationship. This would allow each user to potentially have many different categories and each category to potentially have many different users. This seems like a useful model for what you are trying to do.
I think your schema looks good. You are keeping the category labels in one table to avoid duplication and then just assigning their IDs to the users.
If what you are trying to do is to have "private" categories for each user then this is fine.
If on the other hand categories are supposed to be public (sth like tags on stackoverflow) then you may consider another option - not storing user<->category relationship, instead add field use_counter to category table and use triggers to increment it when category is being used(blog entry is categorized) or decrement when it's "freed" (blog entry is deleted/ its category is removed). When the use_counter reaches 0 - remove the category.