Question:
I have a client that used to be an Oracle programmer years ago who tells me I’m designing his SQL 7.0 database all wrong because I’m using joins in the VB app! He says “joins use I/O on the machine…”, etc. I’ve tried explaining that this is no longer an issue—that joins are used effectively between 2–4 tables all the time, but he won’t let it go.
How can I explain this to him?
Answer:
Assuming that your client is open to reason, you might want to gently point out the following facts:
- One of the main themes of relational database design is normalizing a database. This means that instead of repeating the client address in every single client invoice, we break out the client information into a separate table and join with the invoice table. While this will slow down a query slightly, it vastly speeds up updates to client information (you don’t have to update all the invoice records every time an address changes) and reduces the risk of inconsistent data. As he is using his Oracle experience as his basis for objecting, you can direct him to the sample databases that come with Oracle or even some Oracle books to show him that Oracle recommends and uses joins, too.
- Instead of arguing about it, why don’t you ask him what performance he is trying to achieve? Then simply run a test with a join to show that it meets his requirements.
