title: How costly are JOINs in SQL? And/or, what's the trade off between performance and normalization?
body: <p>I've found a similar thread but it doesn't really capture the essence of what I'm trying to ask - so I've created a new thread.</p>
  
  <p>I know there is a trade-off between normalization and performance, and I'm wondering what's the best practice for drawing that line?  In my particular situation, I have a messaging system that has three distinct tables: messages_threads (overarching message holder), messages_recipients (who is involved), and messages_messages (the actual messages + timestamps).</p>
  
  <p>In order to return the "inbox" view, I have to left join the messages_threads table, users table, and pictures tables to the messages_recipients tables in order to get the information to populate the view (profile picture, sender name, thread id)... and I've still got add a join to messages to retrieve the text from the last message in order to display a "preview" of the last message to the user.</p>
  
  <p>My question is: How costly are JOINS in SQL to performance?  I could, for instance, store the sender's name (which I have to left join from users to retrieve) under a field in the messages_threads table called "sendername" - but in terms of normalization I've always been taught to avoid data redundancy?</p>
  
  <p>Where do you draw the line?  Or am I overestimating how performance-hampering SQL joins are?</p>