I'm working on a website in Laravel where we have realised that what we want to do is setup a matrix where the rows contain buyer IDs and the columns contain seller IDs. Each user on this website is both a buyer and a seller. And in each (buyer,seller) cell contains the quantity that the buyer has bought from that respective seller. This matrix is ordered so that the buyer on the 7th row is also a seller on the 7th column and it also needs to be dynamic in the sense that a buyer and seller can be added or removed. I'm new to SQL and eloquent so how could I go about creating this?
Don't!
Use a many to many relationship on the Users table to realize this. You can use a primary key on the table consisting of buyer_id and seller_id to prevent duplicates. And you can add an extra field to the pivot table to keep track of the quantity.
The database structure of your application should never be changed because of data.
Related
I am using MS-Access database.
I am trying to make relationship with two tables, Old Customer table having data and Newly added coupon table.
As my client want to introduce new concept of coupon, where customer come with coupon instead of giving cash.
I have inserted Coupon code in coupon table in bulk.
Now, I am confused about what kind of relationship I should create with these two tables ?
I have to consider the below things...
customer can give either cash or coupon.
IF customer show the coupon, there will be an entry in CouponID column
as well in cash column (to know the value of that coupon.)
The CouponID should be unique in the customer table, Coupon Code should
not be repeated.
I am confused whether it should be one-To-One or One-To-Many ?
This image will help you to understand the problem.
I would not include "CouponID" in the customer table at all (nor "Cash" for that matter). The customer table models a customer, the coupon table models a coupon.
You need another table to model the transaction:
[CustomerTransaction]
id
date
customer_id
coupon_id
etc...
Every type of independent "thing" should be modeled by a discrete table. and "things" should be related to each other by other tables that create the 1:N relationship.
The relationship of customer to coupon is an optional (ie nullable) one-to-one; your data model looks good.
Some other comments:
The table would be better named sale rather than customer, since if the same customer comes back again, there will be a new row (but with the same name)
You could create a unique index on couponID that ignores nulls
You could rename Cash to Amount; the amount is either "cash" or coupon - the couponID column tells you the type of the amount
To create a unique index that ignores nulls:
CREATE UNIQUE INDEX idx1 ON customer (couponID) WITH IGNORE NULL;
I am creating a purchase order system where someone can store details of their purchase. So I created a database, with tables for supplier information from which we will buy stuff and another table where we store what we are buying.
In the PurchaseOrder table, there are columns for :
PurchaseOrderNo (Primary)
BuyerInitials
DateOfPurchase
ProjectCode
Items (linking to the PurchaseItems table)
I want to add another column with Items' details, so I created another table PurchaseItems which has the following columns:
PurchaseOrderNo. (this would be repeat for each part)
PartNo
Description
Quantity
UnitAmount
VATAmount
TotalAmount
Logically it seems simple, but I can't seem to get my head around on how I would link the tables. Thank you very much for the help :)
Create a seperate table say OrderedItems which maps the PartNo and PurchaseOrderNo. This avoids the repetition of PurchaseOrderNo in each row and also maintains the relation between PurchaseOrder and PurchaseItems table.
Hi i have two tables named as ITEM_DETAILS AND SALES in my database both of them have QUANTITY columns.
I want to make a check that my SALES.QUANTITY table becomes dependent on ITEM_DETAILS.QUANTITY and I want the check that if ITEM_DETAILS.QUANTITY is zero than it does not allow me to SALE any QUANTITY from SALES.QUANTITY.
How I could do that?
I have a check constraint on :
ITEM_DETAILS.QUANTITY>=0
but how sales quantity will become dependent on this?
I'm creating a small pet shop database for a project
The database needs to have a list of products by supplier that can be grouped by pet type or product category.
Each in store sale and customer order can have multiple products per order and an employee attached to them the customer order must be have a customer and employee must have a position,
http://imgur.com/2Mi7EIU
Here are some random thoughts
I often separate addresses from the thing that has an address. You could make 1-many relationships between Employee, Customer and Supplier to an address table. That would allow you to have different types of addresses per entity, and to change addresses without touching the original table.
If it is possible for prices to change for an item, you would need to account for that somehow. Ideas there are create a pricing table, or to capture the price on the sales item table.
I don't like the way you handle the sales item table. the different foreign keys based on the type of the transaction is not quite correct. An alternative would be to replace SalesItem SaleID and OrderId with the SalesRecordId... another better option would be to just merge the fields from InStoreSale, SalesRecord, and CustomerOrders into a single table and slap an indicator on the table to indicate which type of transaction it was.
You would probably try to be consistent with plurality on your tables. For example, CustomerOrders vs. CustomerOrder.
Putting PositionPay on the EmployeePosition table seems off to... Employees in the same position typically can have different pay.
Is the PetType structured with enough complexity? Can't you have items that apply to more than one pet type? For example, a fishtank can be used for fish or lizards? If so, you will need a many-to-many join table there.
Hope this helps!
If I were to have an online shopping website that sold apples and monitors and these were stored in different tables because the distinguishing property of apples is colour and that of monitors is resolution how would I add these both to an invoice table whilst still retaining referential integrity and not unioning these tables?
Invoices(InvoiceId)
|
InvoiceItems(ItemId, ProductId)
|
Products(ProductId)
| |
Apples(AppleId, ProductId, Colour) Monitors(MonitorId, ProductId, Resolution)
In the first place, I would store them in a single Products table, not in two different tables.
In the second place, (unless each invoice was for only one product) I would not add them to a single invoice table - instead, I would set up an Invoice_Products table, to link between the tables.
I suggest you look into Database Normalisation.
A question for your data model is You need a reference scheme will you use to identify products? Maybe SKU ?
Then identify each apple as a product by assigning an SKU. Likewise for monitors. Then use the SKU in the invoice item. Something like this:
product {sku}
key {sku};
invoice_item {invoice_id, sku}
key {invoice_id, sku} ;
apple {color, sku}
key {color}
key {sku};
monitor {size, sku}
key {size}
key {sku};
with appropriate constrains... in particular, the union of apple {sku} and monitor {sku} == product {sku}.
So Invoice table has a ProductID FK, and a ProductID can be either an AppleID (PK color) or MonitorID (PK resolution)?
If so, you can introduce a ProductTypeID with values like 0=apple, 1=monitor, or a isProductTypeApple boolean if there's only ever going to be 2 product types, and include that in the ProductID table PK.
You also need to include the ProductTypeID field in the Apple table and Monitor table PK.
I like name-value tables for these...It might be easier to redesign so it goes 'Product' and then 'product details'...product details holds the product id, the detail type and then the value. This would allow you to hold apples and monitors in the same table regardless of identifying attribute (and leave it open for other product to be added later on).
Similiar approach can be taken in the invoice table...have a 'product_type' column that tells you which table to look into (apple or monitor) and then a 'product_id' that references whatever ID column is in the apple/monitor table. Querying on a setup like this is a bit difficult and may force you to use dynamic sql...I'd only take this route if you have no control over doing the redesign above (and other answers posted here refer to)
First solution is preferential I would think...change the design on this db to the name value pair with the products and you'll save headaches writing your queries later.