I have a query regarding a table structure.We are using single SQL SERVER 2008 Database for two online selling websites.i.e.,The products which the two websites uses are same,but the description about the products are different.For example,we will sell a "Toy" of same price and model on both websites but with different description.At present I used two different id for websites say,Id "1" for Website 1 and Id as "2" for website 2.And also populated the Product table with diiferent Id's for same product along with the description and website id.
Now the problem is I need to find out how many "Toy" has been sold out in both websites together.
Can any one help me out?Should I introduce a separate table structure to relate the Productid?
It seems to me your choices are
minimal change to achieve your purpose
produce a properly normalised design
A minimal change might be that table you propose
A normalised design might be
product
code
standard_description
standard_price
website
code
description
website_product
website_code
product_code
description
price
order
id
website_code
...
order_line
order_number
line_number
product_code
quantity
...
That way the same product has the same code on both websites but you can have differing descriptions (and prices if necessary)
Related
I am designing an online shopping database, however for a specific set of products. The products has the following.
Product Species
Product Category
Product Type
Product Grade
Product Size
Below is my database diagram
In the application, when we select the Product Species, we will be taken to a page where we have to do other selections. In this page there is a dropdown, where we have to select the Product Category. Then the relevant list of Product Types will get loaded. Then select the Product Type, the relevant list of Product Grades will get loaded. Now you can select the product size.
Below is the UI of the applications selection page
HERE THE "C/T" MEANS "CATEGORY AND TYPE"
With my database design, I find it difficult to perform the "selection operation" in the app itself. To load the fresh products after selecting the product species I can simply call select * from fresh_products where idproduct_species=1. But then, how can I find the Product Grades by selecting a C/T? How can I find the Product Spec by selecting the Product Grade?
I know I can run some quarries in the fresh_products table and get this done, even though it won't be easy as a select statement.
If you are interested, below I have shared the product sheet, with dummy information.
To achieve what I need, is my database design a good one or is there a better model?
I'm trying to design tables : Company -> Location -> Products tables for a project I'm working on
So basically a company has multiple locations.
Each location can have the same of different products and also products can have different prices across different locations.
So my question is, how can I efficiently design this use case because my problem is that:
If I put the PRODUCTS under the COMPANY Level --> (Product cannot have different prices etc..) but it is easy to REPORT on when doing analytics.
If I put the PRODUCTS under the LOCATION Level --> It gives me the possibility to give different prices to the same product but TECHNICALLY they are TWO different products on the database and cannot report on them easily.
Is it good to add a PRODUCT table and add another table between location and product (PRODUCT_LOCATION) that will have the price and other properties specific to a location?
Thank you for taking the time to read my question,
You can use a mapping table for Location and Product and then using primary key for this, you can create a mapping table with LocationProductId and Price.
I am curious to know to design the architecture of a database for products with multiple options and pricing for an e-commerce web site
For example lets says.
There are products which has only variant weights and their respective price ( For example apple, apple can be of 500g or 1kg and so the price will very )
There are products with multiple colors and size and their price ( For example cloths they can be of different colors/ different size or both)
There can be products which has different weight, size, colors or can have none of these.
How can i design the database so that what ever the products it is , it should be supported by the database.
For now i can design database which can hold one of them individually , but my objective to design a database which can hold all the above cases.
So far my database design is like this
This is only good , for products having multiple weights and their respective prices, but can't hold all of them.
Simillarly , i can design database where it can hold products with multiple colors and multiple size like small,xl,xxl etc.
But i want to combine all these product types
Objective
Objective is to create a database for an eCommerce site like flipkart.com or amazon.com, which can hold vast variety of products.
Can anyone please help me . Thank you
Entity-Attribute-Value is a bad schema design. You have made it worse by "over-normalizing" the product attribute names and values.
Back off on the latter, then follow the tag to other discussions of EAV.
I have some experience getting data out of database, but not so much in design. To work on this, I'm taking some personal projects and trying to create them in access. I've run across an issue that I was able to get a solution to, but I find it clumsy and was hoping to have some opinions on what I can do better.
My current project is a monthly budget. At this stage I would like a Form to appear as follows:
Category
Sub-Category Budget_Amount
Sub-Category Budget_Amount
Category
Sub-Category Budget_Amount
etc.
I found that I can do this if all the sub-categories are the fields in a table and the category names are hard-coded as labels in the form. However, I would like my table structure to be like this:
Category:
ID
Category_Name
Sub-Category:
ID
Sub-Category
ID_Category
Show_Category
Budget:
Id
Sub-CategoryID
Budget_Amount
The reason I want this structure is that not all sub-categories will be used every month, and in my mind it will be easier to match what was budgeted verses what was spent. I am also trying to practice minimizing space taken up by the database. Are there any ways to do this easily? Or am restricted to my current solution?
I would dive into normalization principles first as you seem not to be too familiar on those principles yet.
"The reason I want this structure..." is not a good reason at all.
Your basic is a sound normalized database structure.
I'd suggest you structure your tables like this:
tblCategory -> CatID (autonumber PK), Categorie
tblSubCategory -> SubCatID (autonumber, PK), CatID (number, FK), Subcategory
As for budgets, I'd expect that budgets tie in into projects. There's no logical reason to tie in budgets directly into any kind of category.
We would need more and escepially more explicit information on what you're trying to achieve.
Similar question:
Database Design Question - Categories / Subcategories
There's sites that could help you to start understanding designing in MS Access, for instance
http://www.functionx.com/access/index.htm
I have designed an ERD for a website I am about to build.
This website has 2 groups: the USER and the COMPANY. Different companies (or shops, to be precise) have the option of logging into the site and enter new products into the system. The users can then log in and view products based on brands and categories.
In the ERD I have created all the tables, fields and one-to-many relations to the best of my knowlegde. I think that went well until the category tables.
I want the products to be categorized in like "MEN&SHOES", "KIDS&CLOTHES". I figured out I am going to need 2 tables for that: CategoryPersonGroup & CategoryProductGroup. But I do not know what is the right approach to link this to the products table. Please help! This is my ERD:
I think many to 1 relations between product and category tables would be convenient such as:
Product (N) -- has -- (1) CategoryProductGroup
Product (N) -- has -- (1) CategoryPersonGroup.
You can use inheritance approach to this matter, i.e. make category table to store any values that are common to all the articles, and then make separate tables that will inherit category table, in which you can store your own values for that tables. And that's it, just link the main category table to persons and voila.