Home/ Questions/Q 658443
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T22:56:03+00:00

Every time a database diagram gets looked out, one area people are critical of

  • 0

Every time a database diagram gets looked out, one area people are critical of is inner joins. They look at them hard and has questions to see if an inner join really needs to be there.

Simple Library Example:

A many-to-many relationship is normally defined in SQL with three tables: Book, Category, BookCategory.

In this situation, Category is a table that contains two columns: ID, CategoryName.

In this situation, I have gotten questions about the Category table, is it need? Can it be used as a lookup table, and in the BookCategory table store the CategoryName instead of the CategoryID to stop from having to do an additional INNER JOIN. (For this question, we are going to ignore the changing, deleting of any CategoryNames)

The question is, what is so bad about inner joins? At what point is doing them a negative thing (general guidelines like # of transactions, # of records, # of joins in a statement, etc)?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your example is a good counterexample. How do you rename categories if they’re spread throughout the various rows of the BookCategory table? Your UPDATE to do the rename would touch all the rows in the same category.

    With the separate table, you only have to update one row. There is no duplicate information.

    • 0