问题
My application is something like order tracking application.
An order is saved in a order table for 300 items. If we process whole items from 1st step then I can place a field of status telling that this order is in 1st step to track the orders and make them available for next steps.
But If machine of step one has capacity of processing 150 items only then I have to mention that 150 items of that order are in step 2 and 150 items are in step 1. And for this I am planning to have tables of each step and save data to respective table.
Order Table: order = 001, items=300 ...
Step 1 table: order = 001, items = 150 ...
Step 2 table: order = 001, items = 150 ...
and so on
My confusion is only this that whether I am doing it right or not. This could be case with many users and how they handle that? Am I doing it right or just overloading the database.
Tables: Below is my tables structure, that I have made. Lot, LotOrder and lotorderdetail tables are related to orders and WindingMain and Dyeing are steps.
回答1:
Usually, when you have items that are in orders, you'll have something like this (if you don't, it would be very helpful if you can explain your database structure):
items
- id
- name
- price
orders
- id
- customer_id
order_items
- id (optional)
- order_id
- item_id
- quantity
- price
The order_items table contains the "lines" of your orders. If you wanted to record fulfilment steps for each order line, you could add a column step.
For example, I might have an order for 100 pens and 500 pencils. Your data structure would be able to reflect that the pens are in Step 1, while the pencils are in Step 2.
If you had some pens in Step 1 and some in Step 2, you could split it into two order_items.
The key point is that you generally don't want to make a set of tables for different values of something (e.g. step), when you can use a column instead.
回答2:
Re steps
Order Table: order = 001, items=300 ...
Step 1 table: order = 001, items = 150 ...
Step 2 table: order = 001, items = 150 ...
Your current design represents certain situations in certain ways. But there is no problem having one table with step as a column:
// order [order] is for [items] items ...
Order(order,items,...)
// order [order] has [items] items in step [step]
Step(order,items,step...)
This has the benefit that now your queries are not limited to either using literal step numbers or using metadata to deal with multiple steps.
Re users
If orders are placed by users then you should add another column:
// order [order] placed by user [user] is for [items] items ...
Order(user,order,items,...)
// order [order] placed by user [user] has [items] items in step [step]
Step(user,order,items,step,...)
There's no "overloading" a DBMS by having many columns or many rows. That is what they are designed for. If anything, most have more have space and time limitations for a large number of tables rather than columns or rows.
PS Re finding & judging designs
Every table has a meaning that is a predicate: a statement parameterized by column names. Eg the code comments above. A row plus a predicate gives a proposition: a statement. The rows that make a true proposition go in the table. We must find sufficient predicates each with a base table to express everything relevant about an application situation.
- if multiple predicates/tables differ only by a common value then you can add a parameter/column and use a single predicate/table
- if a complex predicate/table can be more clearly expressed in terms of the AND/JOIN of simpler ones then you can split up the predicates/tables
- if you have one or more predicates containing the same expression then you can define another predicate to express the originals more simply
- you can define views and computed columns to avoid redundant and contradictory data
Let's focus on just order, items and condition. Note that it is still difficult to query about parts that are either in a step or unprocessed (or finished):
// order [order] has [items] items in step [condition]
OR order [order] has [items] items unprocessed AND [condition] = unprocessed
Condition(order,items,condition)
Or to be able to do arithmetic on all conditions, not just steps:
// order [order] has [items] items in step [state]
OR order [order] has [items] items unprocessed AND [state] = 0
State(order,items,state)
Another thing you can do is define what state means in terms of conditions and steps:
// item [item] is in state [state] means
item [item] is in step [state]
OR item [item] is unprocessed AND [state] = 0
// order [order] has [items] items in state [state]
State(order,items,state)
You can also define State by a view. Its defining query expression is for a table whose predicate is exactly the meaning of the definition above.
The tradeoff: You can have separate tables for unprocessed vs in-process items where querying about condition is more difficult. Or you can have one table for unprocessed and in-process items but the definitions are more complicated.
来源：https://stackoverflow.com/questions/34430117/what-is-the-best-practice-for-changing-status-of-a-record-in-database