SQL Table Design - Same FKs in Parent and Child tables

Question

Columns in Member table:

id           (PK)*
client_id    (FK)
location_id  (FK)
address
etc.

Columns in Member_Vehicle table:

id           (PK)*
member_id    (FK)
mileage
etc.

Is it good design to replicate FKs already in the Member table into the Member_Vehicle table?
So the New_Member_Vehicle table will be

id           (PK)*
member_id    (FK)
client_id    (FK)
location_id  (FK)
mileage
etc.

Most of the processing in our application is around the Member_Vehicle table.
My thinking is - If the Member_Vehicle table readily has the IDs I need, then I can reduce the number of joins between Member and Member_Vehicle tables.

Your thoughts on why this

1. is acceptable
   or
2. should not be done
   
   are much appreciated. Thank you.

Answer 1

What you are considering is called denormalization and is generally a bad idea in a transaction processing system unless you have very good reasons to do it proven out by production performance issues, for example.

As a rule of thumb, your transaction processing system tables should be in third normal form (3NF) and you should back away from this only when needed.

The disadvantage to denormalization is that you could potentially introduce data anomalies (inconsistencies) if there are bugs in your code.

Don't worry about joining tables. That is what relational database management systems are meant to do. Before denormalizing, I would consider other physical database performance tricks, like building a covering index .

Answer 2

Can a client appear more than once in the Member table? If not, the surrogate key there is superfluous. In fact, I'll bet member_id is also a surrogate key. Why would you generate another unique value to stand in for a value that is already unique?

So if you drop the PK from the Member table, make client_id both the PK and FK and change member_id of Member_Vehicle to refer to 'client_id', you're problem is solved.