I have this table
Transactions
- id
- user_id // this will point to which user did this transaction
- item_id // this will point to which item in this transaction
- date
Products
- id
- name
Items
- id
- product_id // this will point to which product this item is
- name
- price
The problem is, overtime, the item's price will change.
To prevent changes in the old transaction history's price
I need a way to keep old item's price.
How can I make the right database design to solve this?
You need to add this info on the Transaction:
Transaction
- id
- user_id
- item_id
- item_price
- any_other_transaction_specific_info
This also lets you apply discounts or any other modifications on the actual price for each transaction.
Its better to save price current product price when transaction is done in transaction table with a price column.
Transactions
- id
- user_id // this will point to which user did this transaction
- item_id // this will point to which item in this transaction
- date
- price
I think you can define a date for each transaction record. on the other hand, you can have another table for recording the product price priceLogs.(like: product_id, price and date). anytime a product's price is changed, a record is added to the table. this will also help you in some more business issues for tracking the price of products.
you need to query the price of each product based on the date of transactions. This might make you write a bit of joins in your query.
In my opinion you should instead create another table as Item_Pricing and this should help you finalize the pricing history. The table Item_Pricing history should be like this Item_Pricing(id[PK], itm_id[FK], price, price_still_in_use, date_price_created,...). The idea is that the colum price_still_in_use should be considered as a flag that can have value 1(yes) or 0(no). Then in your table transaction this is the price that should be considered. Then each transaction or sale should relate to the pricing that still in use as followed :
Transactions
(id[PK],...,item_pricing_id[FK] // this will point to Item_Pricing(item_pricing_id), quantity, date)
So if the item price changes in your application the price of the item should no longer be available if no longer used. A trigger might also help you for best results so that the same item can't have more than one price that has the value yes for the column(attribute) price_still_in_use
Related
I am building an invoice system in which the invoice has many items. my db structure as following
invoices
id
service_prices
discount
final_price
deposit
rest_price_to_pay
total_paid
date
status (1= paid - 2= not-paid 3= deposit
invoice_items
invoice_id
quantity
service_id
price
date
it works fine but the problem is when I need to get a daily report of each item's income to know what income I get daily from each item, it does not work properly with deposits, because when I want to get the daily items income i foreach items from invoice_items table, so when the client does deposit for sure the income will not be the equal of each item price. so i don't know how to solve it in database
you need to modify your database with a more elaborate model. I currently make detailed invoices and even with discount product by product, tax calculation and all the totals...
I use this approach: During a sale I save in a "new sale" table, a new entry, it sends me back its id. With this id in reference I register a new entry in a customer table (with id of the sale) then for each product sold I register a table with the id of the sale and the rest of the data of the sale, id of the article, unit price, quantity, possible discount. This allows me to find all the necessary data when establishing the invoice. In my opinion going through a single table is tedious, how to find the details of each product? And if the product changes price, you will still need to produce an invoice with the correct prices.
I'm designing a database for product rental. I'm using Laravel 8 framework.
prices change all the time.
The rental order requires a quote generated by the client.
The prices are stored but not listed in the user view, they are only for reference in the admin order quote generator view.
The client wants to be able to change the price for each quote before sending it as their specific client may need special treatment.
So, summing up, I need:
To store a record for the price of a specific order quote.
To store a base price and a history record of this price.
To be able to list the available products in between two dates filtered by the status of the order, which will change until the final approval of the quote. Also filtered by the stock available.
Have additional costs associated to the specific order.
Different total price for deferred payment.
This is what I came up to, I have a table for:
Orders
Products
Order_Product (this name format is required by laravel's eloquent)
Products_Prices
Additionals
Orders_statuses
In the order_product table I'm planning to store the price defined for the client, and the count of rented products. Also foreign keys for a many-to-many between products and orders.
In the order I'm planning to store the "pickup" and "return dates to query first WHERE "orders with approved status" BETWEEN the two dates selected by the user. Finally get order_products with a NOT IN to display the available products.
The products_prices table I use it to store the changes record.
In the products table I have availability because the product may not be available for rent for many reasons for a period. Stock and colors that I will use for ordering the list because of a requirement from the client so I go first for primary color, secondary and tertiary afterwards.
I'm not sure if this is the most efficient way to achieve what I'm looking for. Since I will need to check products availability all the time I need to be sure that this is the fastest and more reliable one.
I'm not english speaker so I feel the need to clarify this:
The client = My client.
User = My client's client.
Thanks in advance!
I'm creating an E-commerce mobile application by using Laravel as back-end development.
Scenario: I have a Product table which store some information about the product. Whenever user buys a product, he will get a purchase history record (which will show the product information) that will be stored into the database. So when the seller update their product information, the product information of the user's purchase history record will not be affected.
Problem: If I just simply create a user's purchase history table to store the record for each user, I think it will be a lot of spaces required in the database.
Question: Is there any better way recommended to store the purchase history record? Or is there a way to create something like a 'snapshot' for the record before the product has been updated or deleted by the seller?
Well, this is more of an opinion-based kind of question.
The method that I use personally is the one that you also have in mind: to store the relevant data of product in a separate table. Let's say you have your users, products, and orders tables. A user has many orders, and an order has many products. I use an aditional table details to store product-related info (basically, the relevant data) so, in case of changes in the origintal product, the info still remains correct. You could also store this info in a json column on your purchase history.
Another approach could be to create new product objects whenever these are updated:
Product A (id: 1): price - $10 - 01/08/2019
Product B (id: 2): price - $25 - 01/08/2019
Product A (id: 3): price - $11 - 05/08/2019 (after an "update" on the price of the product)
This way, if someone buys a Product A on 02/08/2019, the price will be $10 and the foreign key in your history will point at the product_id = 1. Of course that this approach isn't the one that I'd use because reporting will be more difficult to handle.
What would be the best, if not, the practical way to design an e-commerce database wherein the product information of the product purchased by a customer should not update when the product information was updated?
To give a better understanding, here's a scenario:
Merchant created "Product A" where it is priced at $50.
Customer saw Product A and purchased it.
Customer visited the transaction history and viewed his recent purchase: Product A priced at $50
Month's after, Merchant updated the price of Product A to $80.
Customer viewed again his transaction history. His transaction with Product A should retain at $50 and not the updated price of $80 because it was the price he paid that time.
One solution I am looking into is to save the whole product information in a table as a PHP serialized data in "purchases.product_information".
Is it even a good idea to store PHP serialized data in a column? How's performance if a user wanted to search for a text in the product information like price, item name, etc.?
Any other workaround for this?
Thank you
It is a case of slowly changing dimensions (https://en.wikipedia.org/wiki/Slowly_changing_dimension)
A simple solution will be to have a separate table purchase_items and have all the columns that may change over time against each item (Example:price, discount etc) and purchase and purchase_items table will have one_to_many relationship
Although, there are more complex situations where the price of the product changes on the fly based on the time at which an order is made in a day etc. In these cases, the price may not be stored against the product itself
This answer is addresses exactly the issue and you might find this helpful
https://dba.stackexchange.com/questions/57992/ecommerce-orders-table-save-prices-or-use-an-audit-history-table
I want to update the ordered product quantity from the sales order view page (admin side). I have added a new button and actions for update order quantity. But I don't know what are the tables needs to updated for this. or else is there any other solution?(without creating new order concept).
I already gone through below one.
Is it possible to update order items quantity in Magento?
Thanks
Orders data are saved in database tables sales_flat_order and sales_flat_order_item.
You can find orders and order items data in your (tables prefix)_sales_flat_order and (tables prefix)_sales_flat_order_item respectively. but remember that when an order is placed Magento simply copies the data from its respective quote. so in my opinion you should be checking (table prefix)_sales_flat_quote and (table prefix)_sales_flat_quote_item first.