Geek asks and answers

The best database structure for orders

I am torn between two ways of structuring my database for order processing. I'm not sure if one path will be faster than another. If they are equal, then that probably doesn't matter, right?

Here is option number 1.

orders
-------
id
timestamp
userID
cartID
reviewed
approved
reviewBy
reviewTimestamp
reviewDetails
processed
processedBy
processedTimestamp
processedDetails

Option number 2:

orders
-------
id
timestamp
userID
cartID
reviewID
processID


reviews
-------
id
timestamp
status
reviewerID
details


processing
----------
id
timestamp
processorID
details

Thanks guys!

+3
source share
3 answers

I would look not only at speed, but also at functionality. Who cares if he is fast, if he limits you too much to be useful. For example, what if you want to view an order twice (the first time you reject something)? Or what if you process the order in two parts? If there is no business case, why you really will never have a multiple of any of them, I would suggest your second option.

, , . , . . , , . , .

, , . , , ( ), , , ( ) , .

, , . , . , , , .

+3

, , .

+1

I would go with a normalized model. If the reviews and processing are many calls with orders, go with option 2. If the reviews and processing are one to one with the orders, option 1 may be easier to work both for reading and writing data (for example, one insert against three).

+1
source

More articles:


All Articles