I think it will help to give a little context, not only about the DB architecture but the actual product. I am building a business where we will be selling pallets of liquidated merchandise. Think a wooden pallet with 10-100 items (every item will have a scannable UPC) on it. Each of these items needs to be listed on the website but we are not actually selling those items. We will be selling the pallet as a single product to the customer.
So, you'll have a
pallet table, a
UPC table, and the join table
UPC_pallet table to establish a
Now, here is the tricky part. Other than the actual UPC codes, I have ZERO product information. That will have to be derived from a bulk API call to a third-party API. In most cases, it will be to Amazon's ASIN API since most of our product will be from Amazon anyway. This wouldn't be a problem if I was simply rendering the information on the frontend for visual purposes but I need more than that - I need the cumulative MSRP from the API call to determine my pallet price. I plan on taking a percentage of the MSRP and setting my price from that.
I am a little loss on how to do this smoothly... I could just determine the price in the front end, and pass it on through the checkout phase into the payment processor but that leaves me zero information on what I sold the item for. After confirmation of payment, I guess I can update the DB on the backend in the
orders section and call it good. Is this an ugly approach?
I am word vomiting right now but I would love a little advice on how you guys would approach this. I am frontend dev (although I have done a lot of Fullstack work like most of us) but this stuff makes me a little uneasy