创建左联接还是向某些表添加一些额外的列？

Question

I'm wondering what would be the best solution (from a performance perspective). I have an Orders table which can have a specific OrderShipment relation. The OrderShipment can eighter be a normal shipping or a delivery at a servicepoint (in the Netherlands, just a drop-off point when you're nor at home like a supermarket, videostore etc).

Currently I'm using a HasOrderShipment field in the Order-table to determine whether or not a second query must be executed to get the Shipment.

When a customer chooses delivery at a servicepoint I need to store the addressdetails of this servicepoint. Now my question is, from a performance perspective, should I extend the OrderShipment table with adressfields (leaving those fields NULL in all other cases except for servicepoint delivery) or create a HasOrderShipmentServicePointAddress table where the addressdetails are stored.

The ordertable is about 5.2m rows and grows with about 21.500 orders per day (avg from 1-jan-11 / 23-jan-11).

Answer 1

Well, with tables that small, I wouldn't personally worry too much about it (And yes, 5 million rows is pretty small in database terms). Is your query too slow now? If so, optimize it. If not, don't worry about it.

Now, as far as your specific question, if you have enough data, you might get away with building a summary table. Since MySQL doesn't support materialized views (views that are indexed and stored on the disk), adding a view won't really help much in the performance terms (but it will help readability). Instead, you could add a summary table. The summary table would be the result of a specific query. So instead of adding the extra columns to the normalized table, you'd copy the table and add the columns to the new one, and then use triggers to keep it updated. The reason I do this in a separate table is that you still have the normalized tables to enforce referential integrity and for the queries that are more efficient with normalized data. But you can use the summary table for queries where you need to do complex joins (you're basically pre-computing the join).

But again, I stress, don't even think of doing something like this unless you have to. Try the normal routes for optimization (indexes, EXPLAIN , rewriting queries, more ram, etc) first. Use a summary table as a last resort...