title: Is it good or bad practice to have multiple foreign keys in a single table, when the other tables can be connected using joins?
body: <p>Let's say I wanted to make a database that could be used to keep track of bank accounts and transactions for a user. A database that can be used in a Checkbook application.</p>
  
  <p>If i have a user table, with the following properties:</p>
  
  <ol>
  <li>user_id</li>
  <li>email</li>
  <li>password</li>
  </ol>
  
  <p>And then I create an account table, which can be linked to a certain user:</p>
  
  <ol>
  <li>account_id</li>
  <li>account_description</li>
  <li>account_balance</li>
  <li>user_id</li>
  </ol>
  
  <p>And to go the next step, I create a transaction table:</p>
  
  <ol>
  <li>transaction_id</li>
  <li>transaction_description</li>
  <li>is_withdrawal</li>
  <li>account_id // The account to which this transaction belongs</li>
  <li>user_id // The user to which this transaction belongs</li>
  </ol>
  
  <p>Is having the user_id in the transaction table a good option? It would make the query cleaner if I wanted to get all the transactions for each user, such as:</p>
  
  <pre><code>SELECT * FROM transactions
  JOIN users ON users.user_id = transactions.user_id
  </code></pre>
  
  <p>Or, I could just trace back to the users table from the account table</p>
  
  <pre><code>SELECT * FROM transactions
  JOIN accounts ON accounts.account_id = transactions.account_id
  JOIN users ON users.user_id = accounts.user_id
  </code></pre>
  
  <p>I know the first query is much cleaner, but is that the best way to go?</p>
  
  <p>My concern is that by having this extra (redundant) column in the transaction table, I'm wasting space, when I can achieve the same result without said column.</p>