I have created a simple stock trading simulation website. Users can sign up and buy/sell stocks. Now, I've come to a problem. When a use buys a stock (can be more than one share), how do I put this into a database?
This is a bit of a challenge because each user can buy any stock that exists and they can buy any quantity.
Here's an example of what I'm trying to store into a db:
Stocks owned by username1261817
Symbol: Quantity
goog: 3
yhoo: 8
aapl: 3
etc...
You might have to design your table like how a shopping cart would do. Include fields - userid (comes from user table), stock symbol, quantity, stock price at the time of purchase, date purchased. This will help you generate the necessary reports like total stocks of one type, total stocks owned by a user etc.
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 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'm working on an order system for my online shop. I have 2 tables:
products, storing info about products
orders, storing general id's & infos of customer orders.
Now I want to have a way to store complex customer orders in the database. I need something that will let me know how much of each size (S, M or L) of each product is in an order.
The tricky part is that I want to be able to add/edit/delete products (of course without affecting orders from the past), so the method should be flexible
How should I go about this?
a separate table for every order, with products as rows?
one table for all orders, with products as columns?
some other option?
Thanks!
Depends on your goals for your cart. For instance, do you want to allow guest purchases? i.e. where a user does not need to login in order to make a purchase?
The attached image is a design I have been working on and it goes like this:
A visitor selects products from the site and adds these to a session cart (just a place to temporarily store the products, their quantities and their prices etc.)
Once the customer is ready to check out, we create the order, the order person and the person_address (where the product must be delivered to) and add the items to the order_item table. All this information is added by the customer in the checkout page.
The final step is then to offer the payment methods: paypal, credit card, etc.
What I like about this design is that users have no obligation to register with us. Order_person acts as a kind of interface between users and orders. If do register, we simply link order_person to the user table...
I have included a sample front end of the checkout page too.
At the very least you need:
Products (one row per product)
ProductID
Size
Orders (one row per order)
OrderID
OrderDetails (one row per product per order)
ProductID
OrderID
Size
Note that each 'size' is its own ProductID. You'll probably want to have yet another ID that groups products that are the same 'base' product, but in different sizes.
So if Order #1 has three products, and Order #2 has four, then OrderDetails will have seven rows:
OrderID ProductID Quantity
1 234 2
1 345 9
1 456 30
2 432 1
2 234 65
2 654 8
2 987 4
I am developing a system of offers and I came up with the following problem:
If I have an offer that buying the "product A" and "Product B" I paid 10% less, I can register as a new offer such a product like Coke, putting the price discounting 10%, ok, but the problem is, if the user select the product A and product B I want to convert it to a discount, ie, selecting the products that generate the discount, the user takes the discount.
My solution is:
I could make a table with the products and set the type of product as normal and promotion, if the type of product is promotion, will have a table associated with the products (in this case the product A and product B), but If I have 10 offers, I need to verify each product to ensure it participates in the promotion, I think soo slow.
Sorry my English, if you don't understand me, leave a comment. thanks!
Setup the products table as normal. Then set up a special offers table and a table for the products included in each offer.
Products Table
product_id
product_name
Offers Table:
offer_id
percent_off
Products_In_Offer Table
offer_id
product_id