Edit: I revised and deleted to clarify. The analogy goes... Every time I get a new customer, I want to automatically create 100 orders for them because I know all my customers want the same 100 items. But they need to be able to change the quantity after they sign up since they want different quantities. Right now I create 100 orders on the client side by .map()ing through the array of 100 orders and doing createOrder mutations in graphql (apollo), is there a better way to do this?
EDIT 2: I believe doing it on the server side at the database makes more sense. Any other advice appreciated.
Can we have a order and sub order kind of concept introduced in database .
If you know that customer is going to order all 100 items , why not create a parent order id for that customer .
When customer checkouts he would have option to edit the number of items in bag .
After customer orders we can create suborder id kind of thing for each item referring to number of items in each order with other meta details .
This would eventually lead to reduction of time in customer sign up and sub order id could be further delayed . This would also lead to reduction of unused data in case customer does not checkouts . 100 rows would be then reduced to 1 .
Related
I have analyzed my as below and I have two point I am confused about
1- currently when I insert an items within orders I give order_ID as a PK
so each item within the order as its own PK... and same customer_id (FK) for all Item within the order so ... in that case the invoice number is same as the customer_ID
Is that what should think goes on or there is something wrong with this work flow ?
2-in some cases I don't need to record the customer information I just want to
insert the orders without their customer info.. I don't have clear idea about how think should happen :S
3- IF I want to apply a discount on some customer orders where the discount should I allow user to able to apply on the item per orders level ?
or on the whole order ? and where the discount column should be stored
1 - This design seems fine for the problem. You are stating that for every product ordered, this is the customer line. You can pick the ID, name, tax/fiscal number, address, etc.
2 - If you don't need any kind of customer information, make the customer_id on the Orders table accept NULL. It is the cleanest way to do it.
If for some reason NULLs are not an option or you want to keep on the database some basic anonymous customer data, you can create a line on customers for anonymous users (Ex.: ID: 1 / Name: ANONYMOUS ...) and place that ID on the order line.
3 - Placing the discount per product ordered might be the better idea.
If you want to apply a discount for the complete order, you just need to place that discount on every single order line.
If you want to apply a discount for a single product, you just need to place that discount on that product line.
If you want to apply a discount for a single product with a limited ammount of quantity (Ex.: Discount of 50% but limited to 1 purchase), and the customers buys more than that limit, you just need to place 2 orders for the same product. One with the discount and max quantity and the other without discount and the rest of the quantity.
Placing this on the order level wouldn't work for single product discounts.
This were answers to your questions. I would also question your design in points like:
If the customer changes address, is your order supposed to change too? If not, you should use the normal approach for orders, which is to have a order header table, with fixed information, like the address and the foreign key to the customer, and a order line table, like your orders line, but with a foreign key to the order header. That also avoids repetition.
Are you expecting up to 2 phone numbers? If you do, the design is ok. If you don't know how many phone numbers to expect, maybe a table with phone numbers, with foreign keys to the customer might be a better approach.
How does one handle situation when you have sales orders and items tables, and then at one point in time you have to change an item. The change will also show up on sales order that have that item. However, lets say that at the time the sales order was place the information was correct but changed later. I don't want older SOs to change what they show for line items and I don't want to have to make new items because it will confuse me later which item is correct.
I noticed that in OpenERP it does just that, keeps the name of part number and description on sales order even if you changed it after sales order was made.
If you are creating new database restructure your Item table. Create a table (for e.g. ItemHistory). have a ItemID and ItemTypeID and DateCreated Fields on it.
ItemID should be used for orders and ItemTypeID + DateCreated will help you to get the current Item.
I'm currently creating a stock management system that uses multiple warehouses (with sub locations) and since this is my first big project I would love some feedback.
Let me show you what I have done so far...
Link as Im still new here
You first need to create a Warehouse, then you can create a Location within that Warehouse.
You can also create an ItemType (ItemGroup), then you can create an Item for that group.
Once you have an Item and Location you can add Stock, the Stock table has a composite key so that duplicates cant be added. I also added a constraint so that you could not enter an Item of the wrong ItemType, same constraint on the Warehouses/Location.
I then need to keep records of each piece of stock, SerialisedItems and NonSerialisedItems. Example: If non serialised stock is added with a quantity of 10 then I currently create 10 rows inside the NonSerialisedItems table (1) that are set to ‘in stock’ with the relevant stock information. If they change the amount of stock then rows would be deleted or added (2).
I could also do with a Van table somewhere that is similar to Warehouse, but think I would have to change the Warehouse table to something like Storage that references two tables, Warehouse and Van?
(1) I currently have a TransactionScope on my page adding x number of rows, Is this the best way to handle that?
(2) The Quantity amount in the Stock table would have to count the number of rows for that item and then update the Quantity each time stock is added or removed, any problems here? - Both Questions Fixed - Only create rows for serialised items.
Any other problems?
Well that’s what I have done, if its good or terrible let me know.
Also if there are any pitfalls I should be looking out for that would also be great to know.
Thanks
[EDIT]
Thanks to Neville K I have made a few changes...
Link to new and improved database
This seems to make a lot more sense! Think I had been staring at it to long yesterday!
Firstly, this is pretty much a solved problem - the best resource I know of is the "data model resource book" series; there's a very flexible model for stock maintenance apps in there.
Secondly, your design is not very normalized, and relies on a lot of duplication. Not sure what the reasoning is, but usually, the "stock" table would have a link to "item", but not "itemType" - the fact that an item belongs to an item type is already captured in the relationship between item and item type, and you don't need to duplicate it. The same goes for location and warehouse.
The key change I'd suggest is the concept of a stock transaction, rather than a single "stock" table.
Something along the lines of
TransactionID date itemID locationID quantity
------------------------------------------------------------------
1 1/1/12 1 1 10
2 1/2/12 1 1 -1
3 1/3/12 1 1 20
To find out the current stock for an item, you sum(quantity) group by item; to find the current stock for an item broken down by location, you sum(quantity) group by item, location.
On the first of Jan, there were 10 items in stock; on the second, 1 item was removed, leaving a stock of 9; on the 3rd, 20 new items came into stock, giving a balance of 29.
This design allows you to track change over time, which is a common requirement; it also provides an audit trail by creating transaction meta data (operatorID, invoice number etc.).
I need a table that stores items and tracks when an item is...
queued
marked for shipping
shipped
marked for return
returned
The table also needs to tell me how many items a customer...
has received in a month
has at home at this time
I tried using inheritance. I assigned each step a typeId (from 1 to 5, each id representing the current step in the workflow). This approach is not ideal because updating a workflow step erases history.
For example, if an item moves from shipped (typeId 3) to returned (typeId 5) we lose an accurate count for shipped items.
How should I approach this? Also, I prefer to keep the data in one table unless I get a compelling reason not to.
Update
Items are mailed to customers incrementally. There are limits to how many items a customer can receive within a month period, and limits on how many items a customer can have at home at any given time. For this example, let's assume 4 for earlier and 2 for the latter. A customers queue can have any number of items. For this reason, items in the queue need to be ranked so the order of items sent can be according to the customers preference.
Items that have shipped already will need to fall out of ranking (the customer can no longer modify rank after an item is sent).
No inheritance here. Time fields are actually date-time. A row is entered into the Tracking table when a customer adds an item to the queue. Other time columns from TimeMarkedShip to TimeReturned are NULL until the action happens. The TimeQueued is part of the primary key in order to allow a customer to rent an item more than once (sounds like video rentals to me).
To count items that a customer has at home you could use something like
select count(1)
from Tracking
where CustomerID = 1755
and TimeShipped is not NULL
and TimeReturned is NULL ;
Rather than a typeID for the current step, it looks like you need a boolean column for each step. Then when you want to count the "net shipped" items, you can subtract the "returned" items from the "shipped" items.
In addition, if you want to track the history, you could make each of these steps a nullable date field, so that you can see that an item was shipped on 3/5/11 and returned on 4/1/11. This may help if you're using this table in other ways, such as managing your shipping/receiving or billing. A NULL, of course, would indicate that the step has not been performed (yet).
I'm currently developing a small customer relationship and invoice management system for my client. And I have run into some small issues which I would like do discuss.
What is the best practice around orders, customers and products. Should my client be able to delete orders, customers and products?
Currently I have designed my database around the principle of relationships between order, customer and product like this:
Customer
ID
Name
...
Product
ID
Name
Price
...
Order
ID
CustomerID
OrderDate
...
Order Line
ID
OrderID
ProductID
Like this I can connect all the different tables. But what if my client delete a product, what happens when he later open a order he created months ago which had that item in it. It would be gone, since it has been deleted. Same goes for customer.
Should I just disable the products and customers when the delete button is clicked or what is the best practice?
If I lets say diable a product whenever my client decides to delete it, what happens then if he later tries to add a new product with the same product ID as a disabled product, should I just enable that item again?
Please share your wisdom :D
"If I lets say diable a product whenever my client decides to delete it, what happens then if he later tries to add a new product with the same product ID as a disabled product, should I just enable that item again?"
Depends entirely on your business scenario - what is unique in the way customers maintain it currently? (say manually?) How do they handle when an old product which was earlier discontinued suddenly reappears? (Do they treat it as a new product or start referring to the old product?) I guess there are no right or wrong answers to these questions, it depends on the functionality - it is always advisable to understand the existing processes (minus the software) already followed by the customers and then map them to the software functionality.
For eg. you could always add a 'A product with this code already exists - do you want to use that instead of creating a new one?' kind of a message. Also, the product ids that you use in your tables as foreign keys, and the ones that you use to show the customer, better be different - you dont want to get them mixed up.
Why would you want to be able to delete orders? I would think that such a system would lock orders so that you know you have a good history. Same goes for customers, why delete them? Perhaps a way to "archive" them, having to set some flag, that way they don't show up on customer lists or something.
As for disabling and then entering a new item with the same product ID - I'm not sure why you'd do that either, each product ID is unique for a reason, even if you discontinue a product, it should keep it's product ID so you have a record. But if you must, then you could put a constraint in the business rules, something to the effect of "If there is no product that is active with this product ID then allow it. If we have a product that is active and it has the same product ID, then throw an error." Thus, you only allow for one active product with that product ID - but honestly, I think this would be confusing, and on the back end you'll want to use a unique id that is unchanging for each product to link between tables.
Instead of "deleting" I would add a boolean column for IsActive. That way you won't loose historical data. For instance, if they are able to delete a customer then they won't be able to look at history regarding that customer and it may make looking at statistical data hard or impossible. For the order table you could have a column that represents something like "current", "canceled", "filled" to accomplish the same thing. That column should be a code to a lookup/codetable.