问题
I'm building a web application for a printing company and am trying to determine the best design for my database.
I have an orders table. Each order has many proofs. However, there are two different kinds of proofs: electronic proofs and physical proofs. Furthermore, if its an electronic proof, I need to store the image source, and if its a physical proof, i need to store a tracking number.
Every proof has many comments associated with it.
It would be nice if i could just have one proofs table, and one comments table, but what is the best way to keep track of the image source and tracking number based on the proof type?
I've considered creating separate tables for electronic_proofs and physical_proofs, but that would require making a separate electronic_proof_comments table and physical_proof_comments table.
The other option would be to have a single proofs table, in which case I could then have a single comments table. However, as I see it, that would require three support tables, proof_types, image_sources, and tracking_numbers.
Any thoughts on the best way, or an even better way of solving this problem?
回答1:
As mentioned in another answer, you only need one table and would simply leave one of the fields blank, depending on the type. However, the difference in my answer would be to relate the order details to the proof rather than the proof to the order details (or order item in their example). Doing it this way allows you to have multiple proofs per order detail.
This is how I would set it up if I were you:
ORDERS
- OrderID (PK)
- CustomerID (FK)
- Etc...
ORDERDETAILS
- OrderDetailsID (PK)
- OrderID (FK)
- ProductID? (FK)
- Etc...
PROOFS
- ProofID (PK)
- OrderDetailsID (FK)
- ProofType
- ImagePath (just path, not image)
- TrackingNumber
- Etc...
COMMENTS
- CommentID (PK)
- ProofID (FK)
- Comment
- Etc...
It would probably also be wise to break ProofType into it's own table, but will work without. If you were to do that, you'd create a ProofType table and change the "ProofType" field in the "Proofs" table to a foreign key referencing the "ProofTypeID" field in the new "ProofType" table.
Hope this helps! Good Luck!
回答2:
I agree with @Ricketts (+1). The tricky part is whether to have columns ImagePath and TrackingNumber in the Proof table, or to normalize them out into separate tables. (Normalize, because they don't depend on the primary key, they depend on the primary key + the proof type column.) If these are the only two columns that are proof-type-specific, then you're probably ok storing them in the single table... but that ImagePath makes me nervous, particularly if its not an image but an actual sizable chunk of binary data. It might make sense for a number of reasons to store that data separately in its own table, but not move TrackingNumber out as well.
Other considerations: what's the ratio between proof types? How is performance likely to work (particularly if there's a BLOB involved in your data requests?) You have to weigh and perhaps test these considerations before making your final decision.
回答3:
I would expect that proof type is just an attribute of the item, as is the tracking number and image source, correct?
It's similar to a situation where some items may come in sizes, but some don't - you just don't populate the attributes that don't matter for that specific type of item.
Also, note that with two different "proof" tables, your order line item table now has to deal with two different entities.
Something like this should be doable for basic use...
ORDERS
Order ID (PK)
ORDER ITEM
Order Item ID (PK)
Order ID (FK)
Proof ID (FK)
PROOF
Proof ID (PK)
Proof Name
Proof Type
Tracking Number
Image Source
COMMENTS
Comment ID (PK)
Proof ID (FK)
Comment Text
You can create lookup tables for proof type, tracking number, and image source if necessary. It really depends on how far you want to go to match reality to relational theory.
来源：https://stackoverflow.com/questions/9591651/how-should-i-set-up-database-tables-for-this-order-situation