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.
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 got my first professional project where I have to create a warehouse inventory web application. I have completed the front-end however I am stuck on the database modal - I'm not entirely sure if I got it right.
(ignore the scribble)
Basically, the company only needs to keep track of their stock level in each of their warehouse and do not need to add supplier details or any cost/sale prices.
These are all the tables and links I could think of however, even though this might work (or not), is this the correct design modal? (specifially the central table)
.
.
Right and Wrong are not absolute. That being said, here is my opinion on your model:
1) Are you sure purchases and sales should be two different tables? They have the same fields. Make them one and add a field that determines whether it's a purchase or sale.
2) The fact that the stock table has the same keys (warehouse,item) that the sales/purchases,inventory, and transfers table does not make it a logical centre table. My design would be:
Tables barcodes,items,warehouses as you already have them.
The remaining tables should have foreign keys on items,or warehouses, or both, whatever exists. There is no reason to make a 2-field FK towards the stock-locations table
The transfers item should have both warehouse_from and warehouse_to FK referenceing warehouses. And item, of course.
I have to develop a shopping site where I need to maintain data like "Add to Cart" and "Previous Orders" for a single user, for N number of users in a database. E.g. if there is a user named "Mark" and I need to store his 5 items previously added to cart and 4 items as previous order and there are say 100 users like him whose data I need to store, How should I solve this problem? I am using PHP and MySQL.
Each user is assigned a unique ID (you can exploit MySQL's AUTO_INCREMENT for this purpose when creating the table of users.
Then, for items the users select, you create another table including the User_ID (from the previous table), the Item_ID (from a similar table for items), the status (that would indicate the status of the item for the specific user) and an optional field that would contain the order number when the user places the order (for one or more items).
In summary, and since you are actually asking for help in designing your database, I would suggest you sit with a pencil and a piece of paper and make lists of informational elements that you need, marking the one-to-one relation between them (when applicable). This will (approximately) suggest what needs to be arrange in a record of a table (e.g. all the stable details of a user would normally go together into a single table).
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.
I have 4 tables (with a lot of fields, but only a few important ones in each) that I'm working with.
Customer table
Inventory table
Invoice table
Invoice details table
What I've been doing is getting a customer or item's id.
If it's a customer, I take their id to get their information from the customer table. Now, in order to get the item's they carry I have to look at each invoice with that customer's id. So I grab all of those. Each invoice has and id that links to an invoice detail table, so I take that invoice id and grab the invoice details that match with the invoice. Then the items are in the iteminventory table, so I take the item id from the invoice detail and get all of the items for every invoice associated with that customer. Then I run that data through a loop to get rid of any empty values and pass the item array to the view.
Now if it's an item the actions are performed vice versa. I take the item, look at each invoice detail containing that wine, grab the invoice id from it, and grab the customer id from each invoice respectively.
Somehow I wind up with customer's carrying a product, but when I go to the product to see what customer's carry it, the previously mentioned customer won't be listed under the product.
Is there an easier way to do this?
Most SQL programmers solve this kind of problem with a single query using a series of JOIN directives and an appropriate ORDER BY directive. They write a bit of php code to read the resultset row by row, detect rows in which the invoice id changes, and format the information appropriately.
It seems like a good idea for you to read up on how to use JOIN directives if you don't already know.