Right now I have US products in my database only. They reside within a table named products. These products are searchable through assigned tags which are in a separate table.
My challenge is to now add products from a different country with the requirement that wherever the user is from he will only see products from his country.
The country can either be selected by these infamous country-flag-picker dropdowns, set in the user profile or first determined by the visitors IP.
How would you store the international products in the database? Presumably there will not only be one more country added but many more.
Would it either make sense to simply add a column in the products table which country this product belongs to or
have a mapping table or
have separate tables for each country or
something totally different?
Right now I can not say for sure that each product will only be sold exclusively in one country. So I have to assume that one product may be sold in more than one country.
Looking forward to hear your thoughts on this.
That's a classical many-to-many case.
Create a country table and a reference table which stores links between countryID and productID. That way you'll be able to sell a product in only one country or as many countries as you want.
There is a lot of information on SO about many-to-many relationships: https://stackoverflow.com/search?q=many-to-many+mysql
Related
I have a particular problem from my assignment which goes like this :
"Each product making up a set is supplied by a single supplier and is given a unique ID,. Products are always sold as part of a set, never on their own."
So based on this is assumed Many Products creates One Package(aka set), but i don't know if i'm right, if so how can I visually show a Many to One relationship as an ER diagram.
I have constructed my own Conceptual and Logical ER diagram, I just need to know if i'm right or wrong so that i can continue with the rest.
Here's a breakdown of the assignment and what I get from it:
Each product making up a set is supplied by a single supplier and is given a unique ID,. Products are always sold as part of a set, never on their own.
From this I get that we have these entities:
Product
Supplier
Package (Set)
You should know that each Entity needs its own primary key. Pros will either call this id, or product_id. There are ORM's that tend to work best out of the box, if you name the pk for each table 'id', especially when it is a simple sequence number.
It's also better not to do what you are doing with attribute names. In sql people stick with either all uppercase or all lowercase naming rather than camelcase. Also I'd suggest that you don't name the price attribute pPrice just because it's in the Package table. Just name it price, because it can be referred to as Package.price if you need to tell it apart from some other table that also contains a price column.
The important thing to understand is that the relationship between Package and Product is Many to Many
One Product can be part of Many Packages.
One Package can contain Many Products
In order to create entities for a Many to Many relationship, you need a table that sits between the 2 tables and will have foreign keys to both tables in it. Typically people will pick whatever they consider the dominant side -- I would probably use Package, and name the table "PackageProduct" to reinforce the idea that this table lets me package products together and sell or distribute them.
PackageProduct
--------------
id (pk)
package_id (foreign key to Package table)
product_id (foreign key to Product table)
You also need a supplier table, but you were informed that the relationship between Package and supplier is that a Package can have one and only one Supplier.
This is code for: create a one to many relationship between Supplier and Package. In doing this, Package will have a foreign key in it that stores the Supplier.id (or supplier_id)
So to conclude you should have these entities (tables):
Package
Product
Supplier
PackageProduct
ERD
Here's an ERD rendered with "Relational" format which I find a bit more descriptive, as the many sides of the connections use the crowsfoot, so it's very obvious.
According to your description your schema will have one to many relation i.e your single package comprises many products.
You can also find out your ERD diagram
I am designing a database for a website. I have 4 tables for posts. The first table is the master table that should assign a new ID and title for every single post regardless of the post type. The three other tables are cars, houses, and furniture tables. Each one of them should only have the post that is related to it. I am little bit confused of the type of relation between master table and other tables; should it be one to many or one to one. that is, in the cars table, there are columns for price, detail, manufacturer, type, cylinder, fuel, and so on. so, in the master table if the type of post is car, then, this post should be assign a one id in cars table with unique manufacturer. Therefor this is one to one. and each post in the cars table has a correspondent post id in the master table( one to one relationship). while each manufacturer may have many posts in the master table. hence, I assume this is one to many relationship. This is the same case with other tables.
please I do not need any referring to any documentation since I read all mysql official documentation and I know the theoretical prospect of all relationship types but when I turned into the practical part I became little bit confused.
If you want to know if the relationship between X and Y is one-one, many-one, or many-many, ask yourself these two questions:
Can one X have multiple Y's?
Can one Y have multiple X's?
Now count the Yesses:
0: One-one
1: Many-one
2: Many-many
For example, a manufacturer can have multiple cars, but a car only has one manufacturer, so that's many-one. The post/car relationship isn't as clear to me from your description. Can a post have multiple cars? Can a car appear in multiple posts?
You are right on the track, I ll suggest you to store all the post in post table as auto-increment id. Whenever you get any post of any type, make an entry in post table with suitable type. Also make entry about manufacture in post table.
Now take this post id and make a corresponding entry into cars/house/furniture table depending on the type, here in these table add additional details like price etc respectively.
So now post table becomes central repository of all post - depending on many types and manufacturer. You can later add/remove types of post accordingly. making it a scalable.
Further, you thinking right in terms of relationships where you have many to one relation between manufacturer and post(since one manufacturer can post multiple times), and one to one relation between post and its type(since a single post at any point in time will only belong to only one type).
I am running an e-commerce site with multiple stores and each store having its products. I currently have a table called product-store which has a list of all product id referencing the products name and description from a different table , prices etc and their corresponding store ids. This table could have same product repeating multiple times if multiple store carry it.
I am mooting the idea of having a separate table for each store(product-store1, product-store2) rather than having all stores in one product-store table. I could be adding 100 stores and hence 100 tables like this. The structure of each table is the same but the reason why I am thinking of doing this is for better encapsulation of data from the other stores. However this would also mean identifying the corresponding table first for the store and then fetching the data.
I need help in assessing if this is a right approach and how I can measure the two approaches.
There are very few good reasons for splitting a table into multiple tables. Here are reasons not to do it:
SQL is optimized for large tables, but not for lots of small tables with the same structure. (With small tables, you end up with lots of partially filled data pages.)
Maintenance is a nightmare. Adding a column, changing a data type, and so on has to be repeated many times.
A simple query such as "How many stores sell a single product?" are problematic.
You cannot have a foreign key relationship into this table, for instance, to have a history of prices or discounts on the product in each store.
A single table is almost always the best way to go.
I guess it also depends on if the products might be shared across different stores. I would not go the way of creating x tables for x stores, but a general structure to be able to hold all the information.
If so, you could set up at least three tables:
product (holds all the generic products information, shop independent)
store (information about the stores)
store_product (links the products to the stores)
This way you can add as many products / stores to your system without having to change database structure (which is bad anyways).
To answer some of your assumptions:
Encapsulation of data from different stores is rather selecting a subset of data that choosing different tables.
whenever you need some additional information (not being thought of in the beginning) for either stores or products, its easier to add by referencing the new table to stores/products instead of having to multiply those changes by the amount of stores.
I'm creating an EER Diagram with MySQL Workbench.
What is the best way to implement a relationship between products, categories and companies tables?
I was thinking in this relation, but is this the best way considering I want to allow custommers of a company to manage their own products/categories? Isn't this a problem if I want to list only the categories of a company?
The second relation I designed is this one:
Which one is a good relation for my purpose? Or should I use an another one that can make it easier to manage only the products of a company or only the categories -> products of an company?
You should use the second one if every company should be able to have its own categories. Think about it if you would not have a company_id in your category. Then you would not be able to assign a category to a company. Also please declare your foreign keys like "category_id" and not "id_category". First one is better readable.
The best way to describe this scenario is to use an example. Consider Netflix: do they
store their orders (DVD's they mail out) in a separate table from their member lists (NOT members table, but a joiner table of members and movies--a list of movies each member has created), or are orders distinguished by using additional information in the same row of the same table?
For those not familiar with Netflix, imagine a service that lets you create a wish list of movies. This wish list is subsequently sent to you incrementally, say two movies at a time.
I would like to implement a similar idea using a MySQL database, but I am unsure whether to create two tables (one for orders and one for lists) and dynamically move items from the lists table to the orders table (this process should be semi-automatic based on the member returning an item, where before a new one is sent out, a table with some controls will be checked to see if the user is still eligible/has not gone over his monthly limit)...
Thoughts and pros and cons would be fantastic!
EDIT: my current architecture is: member, items, members_items, what I am asking is if to store orders in the same table as members_items or create a separate table.
Moving things from one database table to another to change its status is simply bad practice. In a RDBMS, you relate rows from one table to other rows in other tables using primary and foreign key constraints.
As for your example, I see about four tables just to get started. Comparing this to Netflix, the grand-daddy of movie renting, is a far-cry from reality. Just keep that in mind.
A User table to house your members.
A Movie table that knows about all of the available movies.
A Wishlist or Queue table that has a one-to-many relationship between a User and Movies.
An Order or Rental table that maps users to the movies that are currently at home.
Statuses of the movies in the Movie table could be in yet another table where you relate a User to a Movie to a MovieStatus or something, which brings your table count to 6. To really lay this out and design it properly you may end up with even more, but hopefully this sort of gives you an idea of where to begin.
EDIT: Saw your update on exactly what you're looking for. I thought you were designing from scratch. The simple answer to your question is: have two tables. Wishlists (or member_items as you have them) and Orders (member_orders?) are fundamentally different so keeping them separated is my suggestion.
A problem with storing orders in the members table is that there's a variable number (0, 1, or several) of orders per member. The way to do this using a relational database is to have two separate tables.
I feel like they would store their movies as follows (simplified of course):
tables:
Titles
Members
Order
Order_Has_Titles
This way an order which has a foreign key to the Members would then have a pivot table as many orders could have many titles apart of them.
When you have a many to many realtionship in the database you then need to create a pivot table:
Order_Has_Titles:
ID (auto-inc)
Order_FkId (int 11)
Title_FkId (int 11)
This way you're able to put multiple movies apart of each order.
Of course this is simplified, and you would have many other components which would be apart of it, however at a basic level, you can see it here.