I am trying to create a sql table for orders. We have another table what has a primnary key of productID. When a customer creates an order it should list the orderID as well total and a foreignkey of productID. The issue I have is that it only allows 1 productID.
Is there a way for sql to add multiple foreign keys to the same row for the same item? If that makes sense?
I placed both tables here to try and show what I meant.
Your table structure only allows one product per order, because you've got a single productId column on the orders table.
To allow multiple products per order, I would create an orderItems table. Each orderItem has a different productId, and links back to the orders table via an orderId. Like this:
------------------------
orders table
------------------------
orderId (primary key)
orderDate
orderTotal
customerId (foreign key)
specialInstructions
-------------------------
orderItems table
-------------------------
orderItemId (primary key)
orderId (foreign key)
productId (foreign key)
quantity
-------------------------
products table
-------------------------
productId (primary key)
productTitle
productDescription
productPrice
Related
I have a DB in PostgreSQL with 2 tables, customers and orders:
In customers, among all the columns, I have the customer ID (Primary key) and number of orders.
In orders, among all the columns, I have the order ID (Primary key) and the customer ID (foreign key)
When I insert a row in orders, I'm doing an update of customers and I do number of orders = number of orders + 1. However, now I will need to delete orders, and I was thinking if there is a better way of having control of number of orders. Is there any constraint I could do that would be beneficial for me?
Can I remove a row in orders and substract 1 in number of orders in a single transaction?
I have to build a database as follows:
We have one table, called Organization. An Organization can have one or more products, which they sell. Then, I have a table called Products, which lists the Product title, cost, and amount sold.
How can I create a relationship where a organization.product can contain a reference to multiple rows from the products table?
I would imagine I would need to potentially create another table?
Thanks!
Assuming you have something like this for your Organization and Product tables.
Organization
Id (Primary Key)
Name
....
Product
Id (Primary Key)
Name
Cost
....
Then you would create a join table like this that would link your Organization to Products.
OrganizationProduct
Id (Primary Key)
OrganizationId (Foreign Key to Organization Table)
ProductId (Foreign Key to Product Table)
What you want to do here is have a table representing your products and in that table one of the fields should represent the Organisation which has the product, called something like org_id.
Then in your Organisation table you will have an id column to join with org_id from the product table.
Eg:
Products:
id int
org_id int
name varchar
colour varchar
.....
any other information about products
Organisations:
id int
name varchar
type varchar
...
other organisation details
Now when you want to list all the products for each company you do:
SELECT products.name, organisations.name
FROM products
JOIN organisations
ON products.org_id = organisations.id;
New information, products can belong ot multiple organisations. Now you need a table called organisationProducts to act as an intermediary between the two tables and create a many to many relationship:
Products:
id int
name varchar
Organisations:
id int
name varchar
OrgnisationProducts:
id int
Org_id
Prod_id
You join prod_id to products.id and org_id to organisations.id
What you want is called an associative table. Let's call it OrgProduct (I name all my tables in the singular; some shops name them plural, but be consistent).
OrgProduct will have at least the Organization key and Product key as columns, and the combo of the two keys will be the key to OrgProduct.
If there are properties of the relationship, such as a date when the right of an Organization to sell a Product expires, these would also be candidates for non-key columns in this table.
I have what may be a stupid question but here it goes.
I have an ORDER_T table, a CUSTOMER_T table, and a ORDERLINE_T table.
I also have a set of data I need to normalize. Each record in this "bad data" has up to 3 items stored in it in attributes called Item1, Item2, and Item3. I thought I was normalizing it correctly by taking each item, separating it, and having it constitute it's own record was good. For example
ORDER_T
OrderID ItemID ItemDescription CustomerID
1 1001 Apple 100
1 1002 Grape 100
1 1003 Pear 100
OrderID is the PK and CustomerID is the FK. I realize thought as I tried to INSERT INTO my DB that it complained of multiple duplicate records via the PK. Duh--that makes sense. Now my question is:
I believe I am wrong but what would be the correct way to normalize data (to the third form) where each OrderID consists of multiple items? Is having attributes such as Item1, Item2, Item3, etc. "bad form" where it is not scalable and statically set like that? Am I overthinking it and should have simply left it alone?
I just believe I need some direction and I'll be good to go.
you need next tables:
all unique customers
customers:
CustomerId (PK)
Name
all unique items
Items:
ItemId (PK)
ItemName
all unique orders:
Orders:
OrderId (PK)
CustomerID (FK)
OrderDate
and then you need many-to-many relationship table:
OrderItems:
OrderId (FK)
ItemId (FK)
count
primary key (OrderId, ItemId)
then you will be able to insert order (which can be empty), then add/remove items from this order via OrderItems table
Im a newbie here
I created one table with primary key customer_id , and another table with a foreign key customer_id to join it to the first table
my question
when I want to enter data in the two tables , should I insert the customer_id twice ( one in the first table and the other in the second ) .
should I do that in every time I insert data ??
thanks :)
Your CustomerId table represents each customer in the Customer table. So whenever a new customer arrives, you create an id for that customer.
For other tables that "relate" to the customer, you insert a customer_id for each entry.
E.g.
Customer
CustomerId, CustomerName
Each customer has a unique id..
ProductSold
ProductId, ProductName, CustomerId
You can now tell which customer bought a product because of the foreign key in the Product table.
So for each product, you insert the customer's id that bought it. I hope that makes sense.
-- A new customer, requires a new id (when you insert a new customer)
-- A product bought by customer, requires a foreign CustomerId to identify its buyer.
So 2 CustomerId inserts.
So yes.. you are right lol :P
I am making a piece of invoicing software and I want it to save each individual invoice.
The user creates invoices by selecting a customer, as well as however many items are being billed to the customer. Seeing as most invoices will have multiple items, what is the best way to save them to the database without being incredibly redundant? I'm willing to rearrange my entire database if need be.
My tables look like this:
Customers Table:
Id / Primary key
FullName
Address
Phone
Items Table (a table of products offered):
Id / Primary key
ItemName
Price
Description
Invoices Table (saved invoices):
Id / Primary key
CustId / Foreign key is Id in Customer table
ItemId / Foreign key is Id in Item table
Notes
You need another table to store invoices (what you call Invoices now actually stores invoice items).
Customer
id
name
etc.
Item
id
name
etc.
Invoice
id
cust_id
date
InvoiceItem
id
inv_id
item_id
This is the classic way of modeling a many to many relationship using a junction table (i.e. InvoiceItem).
It looks like you will actually want a 4th table to join them. To normalize your data, only keep on each line things that are specific to that invoice
Invoices table
Id / Primary key
CustId / Foreign key is Id in Customer table
Notes
Invoice Items table
InvoiceId
ItemId