CODEWITHSUNDEEP
sqldatabasedatabase-designentity-relationshipshopping-cart
user478636
user478636

Reputation: 3424

ERD for ShoppingCart

I'm a bit confused about the entity relationship diagram for my application.

So far I have made tables for Product,Customer,Category

Should I make a table for UserAccounts that holds the id and password for the Customer or directly place the the id and password in the Customer table?

Secondly, each customer will have his own cart. So I have made a CartItem table

CartItemId, ProductId, CategoryId, Description, UnitPrice, TotalPrice

But this table is not associating a customer with the cartItem in the shoppingcart. So Should i add the CustomerId here also?

Is there a need for Description and unit price, because those are already defined in the Product Table?

and for Cart Table, CartId, CartItemId, CustomerId

I need to clear up a few things, before I find any mistakes in my application.

DDL:

   CREATE DATABASE ShoppingCart

   Create Table Customer(
   CustomerId int PRIMARY KEY,
   Firstname varchar(50),
   Lastname varchar(50),
   Address varchar(50),
   City varchar(50),
   State varchar(50),
   Country varchar(50),
   Mobile varchar(50),
   Phone varchar(50),
   Email varchar(50)
   )

   Create Table UserAccount(
   UserName varchar(50),
   PasswordHash varchar(50)
   )

   Create Table Category(
   CategoryId int PRIMARY KEY,
   CategoryName varchar(50),
   CategoryDescription varchar(50),
   CategoryImage varchar(50)
   )

   Create Table Products(
   ProductId int PRIMARY KEY,
   ProductName varchar(50),
   Description varchar(50),
   CategoryId int,
   UnitPrice money,
   DateAdded datetime,
   thumn varchar(50),

   CONSTRAINT fk_CategoryId FOREIGN KEY (CategoryId)
   REFERENCES Category(CategoryId)
   )



Create Table CartItem(
CartItemId int,
ProductId int,
CategoryId int,
Description varchar(50),
UnitPrice money,
TotalPrice money,

PRIMARY KEY (CartItemId),
CONSTRAINT fk_ProductId FOREIGN KEY (ProductId)
REFERENCES Products(ProductId),

CONSTRAINT fk_CartItem_CategoryId FOREIGN KEY (CategoryId)
REFERENCES Category(CategoryId)

)

Create Table Cart(
CartId int,
CartItemId int,
ProductId int,
CategoryId int,
Description varchar(50),
UnitPrice money,
TotalPrice money,

PRIMARY KEY (CartId),

CONSTRAINT fk_CartItemId FOREIGN KEY (CartItemId)
REFERENCES CartItem(CartItemId),

CONSTRAINT fk_CartItem_CategoryId FOREIGN KEY (CategoryId)
REFERENCES Category(CategoryId),

PRIMARY KEY (ProductId),
CONSTRAINT fk_CartItemId FOREIGN KEY (ProductId)
REFERENCES CProducts(productId)

)

Upvotes: 2

Views: 6671

Answers (1)

Cade Roux
Cade Roux

Reputation: 89661

#1 Do not store the password - store a salted hash.

Do not make the customer Id in the cart item table if it's already obtained through going through Cart table.

Right now, I think you are confused with having a Cart and CartItem table which are nearly identical.

UserAccount appears to be orphaned. It needs to be either in the Customer table or somehow linked.

I would drop CategoryId, Description, UnitPrice and TotalPrice from CartItem (since they are in Product) unless products are customized into the shopping cart for each customer. You also run the risk of letting a user check out with a product at an old price (unless you treat carts as quotes, which is a whole other business domain).

A CartItem needs a way to get to its Cart or Customer.

Here's what I would do:

Category (CategoryID (PK), etc.)

Customer (CustomerID (PK), etc.)

Product (ProductID (PK), CategoryID (FK), etc)

Cart (CartID (PK), CustomerID (FK), ProductID(FK), Quantity)

When a cart becomes an order, typically an order detail or invoice detail table will lock in the price, and perhaps the name of the product, and the cart will be emptied for a custoemr. A lot of this depends on further business needs.

Upvotes: 3

Related Questions