Hello how are you? I wanted to ask you who have more experience than me if what I want to do is a good or bad practice in Laravel.
I am making an ordering app and in my database I have that a product has a certain price (one more field in the product table). But then I realized that when the price of the product one day changes, the price will also change in an old order, that is, the old order will adopt the new price of the product at this moment and not on the date when the order was placed, thus generating an information problem.
For that, I decided to create a new table that has the temporary prices, that is, if the price changes, that a new row is created in the database with the price on a certain date, but that the price it had in another is recorded. date.
Now, my question is ... How can I bring the current price of a product to that new table that I am creating, without the user intervening ... that is, migrate all the prices of each product to that new table.
My idea was to create a function that goes through each product and that creates a new row in the prices table with the product id, the price and the current date. Once this function is created, run it through Tinker and that the user does not notice absolutely nothing, but that the system adopts the new price structure.
This is good?
Is it a good practice or is there a better way to do it?
Thank you.
welcome to SO! This is one possible way to do it to have a table with the price history incl. start and end date of validity. To not overcomplicate the queries for showing the user his order history I would recommend you also to save the price of the product in the order. For example in the many-to-many mapping table between order and product, where you can also save the amount of the purchased products.
You could make a CLI command (e.g. php artisan make:command InsertOrderPrices) then to fill these fields for the old orders after you created them.
Related
Is it possible to save the state of the database at given time in doctrine?
Why? well for example lets say I seed a database with Products table and Customer Table and then we have 1 Products record and 1 Customer record. Then I do some crud activity on the Products table that I now have 3 Products and changed the name of the original first Product. But now for the next test or time I want to reset to state back to where I was done seeding So then when I start doing the Customer testing I start with a Fresh database with out having to reseed the database?
Can I for example hook into the even system and see which products gets created and then fix the database after or some kind of back up and reset it towards that state?
Any advice will be appreciated
Quick note I dont have access towards PHPunit
I am designing as a project a web store (using PHP Laravel and MySQL FYI) and I am at the part where I have to create the logic behind the production system, which goes like this:
-On my Database,
I have 1 ORDER table where I have all the information regarding the shipping, customer, etc.
I have another table called ITEM where are listed all the Items in an order (so if an order has 3 items, there will be 3 lines in the ITEM table with a Foreign Key pointing to the ORDER).
Now I'm creating the PRODUCTION DASHBOARD. Right now I'm able to scan the item ID and get the shipment information on the Dashboard.
After that, for orders with multiple items what I want to do is for the system to tell the user to deposit the item in a numbered box to wait for the rest of the items from the order. That way the user can keep scanning items from other orders and once another item from the ordered stored in X box is produced, he can scan it and the system will then tell him that the other items from the same Order and placed on X box and he can do that until the order is complete.
My question is what would be the best way and logic Database wise (and also Laravel wise if you want to further expand your answer hehe) to implement this BOX system.
I hope my question is clear enough and thank you very much :)
I had a similar system for a project that I was working on. What I did was, was create a database table called temp_orders with a column called items that each item was separated by a line break. Until the order was finalized (100% processed), the order would remain in temp_orders.
Once finalized, it would get deleted from temp_orders and moved over to the orders table. If I needed to check items, I would explode() the data from the items column in temp_orders table using a line break, thus putting them into an array and then using the data however I needed to.
You need to determine when you want to finalize the order. It could be upon credit card payment, or upon user order confirmation, for example.
I use PHP for solving this task. But that's not the point.
Every morning I get four files each of them contains nearly 6000-8000 records having the following form:
Product name
Package
Producer
Price with tax
Expire date
Rest
Series
Parsing these records I get the table of products. Later clients make orders so I need to keep id of item in the order table. (clients would like to see history of purchases)
All is fine. The arising problem is that one day any of suppliers can send completely different price list. I.e. some products will be removed and others will be added. So it would be completely wrong to rely upon they order in the price list.
What I've come to is to parse catalog blindly adding all items one time. Every next time when I get catalog I need to add only new items and remove the old one from DB. (though not actually removing but just marking as deleted so that no new purchases would be possible )
For deciding whether item is new or not I will retrieve record by record from Excel file and check "Product name", "package", "producer", "series" fields in conjunction against the table with products.
If no such item is found I assume that this is a new item and I'll add it to DB.
What to do with deleted items? I'm not warned about deletion of them. So I can't find out what items are missing in the new Excel file. The solution is to scan DB item by item and see whether all items in DB are present in Excel file. If some item is missing then I will mark it as deleted.
Once deleted items can be back for selling. So I will need to select all deleted items and check one by one against Excel file. If item appears in Excel file - I add it back.
It's worth to note that some suppliers give their catalogs as Excel files and others as DBF files as for now. Who knows what formats will come in the future. Also the number of suppliers is supposed to grow up (next month we get 2 more into play).
My question. Is there any better way to do it more efficient? I'm afraid that my method is too straightforward.
Having 8000 records and doing 3 checks I will get O^2 complexity for every price list making whole search through MySQL Db. Perhaps it will work for 8000 records but I'm sure it's going to fail when one day I get price list with let's say 10^5 record.
Is there a better way to organise it?
Thanks.
Is there a field in the Magento database which holds the date for when an order is shipped?
The only date fields I've come across are created_at and updated_at but i don't think that's what i need.
Thanks for any help.
First off, the hierarchy of objects/database tables surrounding orders underwent a major reorganization from EAV style objects to "flat" objects during the 1.4.x branch. This specifics of this answer refer to modern versions of Magento.
When you create a shipment in Magento, you're creating a sales/order_shipment object. These objects are stored in the sales_flat_shipment table. This table has created_at and updated_at columns.
Each of these order shipment objects links to a 1 or many order shipment items objects. These objects are stored in the sales_flat_shipment_item table. Each row in this table represents a shipped line item in the order. This table links back to sales_flat_shipment by its parent_id column, and can be used to ensure a particular product, as well as its quantity, shipped.
Keep in mind that in most large scale e-commerce rollouts, Magento isn't the ultimate "source-of-truth" for what has and hasn't shipped. Every ERP integration I've ever seen is a lump of undocumented custom code that's used to communicate with an oversold bit of warehouse management software. The above data is usually used as a flag to a larger system that an order is ready to ship. Whether it has or not depends entirely on your process.
$shippingDate = Mage::getModel('sales/order_shipment')->getCreatedAt()
Comes from the sales_flat_shipment table in the magento version i'm running.
If you want to display actual shipping date then this date stored in 'sales_flat_shipment_grid' table. You can fetch data from this table using Mage::getResourceModel('sales/order_shipment_grid_collection');.
If you want to check then you can check from shipping grid at 'admin->sales->shipping'.
If this one help full then please up vote. :)
I want to take a snap shot of a row in a MySQL table.
The reason being, if someone buys a product. I want to take a snapshot of that product to store for the order.
It needs to be a snapshot to maintain data integrity. If I just assign the product to the order, if the product changes in the future the order will show those changes. For example if the price changes, the order will now load the new data and say that it sold the product at its new price rather than what the price was when the order was placed. So a snapshot needs to be assigned to the order instead.
The way I did this in the past was having 2 tables, one for products, and one for snapshots of products. The snapshot had every column as the regular table plus extra colums like order_id
I had a script to take a snapshot that automatically looked at the fields in the regular table and tried to do an insert into the same fields into the snapshot table.
The biggest problem with that approach is that, if I added a column to the regular table and forgot to add the same column to the snapshot table; the script would try to insert data into a non existent field and fail.
I also disliked the idea of having 2 tables that were nearly identical. I think maybe figuring out a way to use one table for both purposes might be better.
So I am wondering if there is a known method I am unaware of to solve this issue?
My previous project used no framework but my next one will be using CakePHP if that matters.
I think the best way of handling this would be to roll the "snapshot" information into an orders_products table. So if you have an order, store the total price, tax, etc. information in a single row on the orders table and reference that order_id on your orders_products table. On your orders_products table, you can have order_id, product_id, price, quantity, discount and whatever else you need.
Seems like your previous is fine. But that you just need to do more testing to ensure that you don't forget to add the new fields to the snapshot table. Seems like a basic test that would be easy to do. The other alternative is to just use a big text field, and store the snapshot as XML. This will let you store the snapshot regardless of if the schema changes. Depending on how much you want to query this data, it may or may not work for you.
Also you may not want to store every field, as it may just take up extra space. For instance, if you have the location of the image file of the item, you may not want to store that, as it may not be important at a later date. You could try querying information_schema to query which fields are in the snapshot table, and only copy the available fields.