Question

So I’ve read enough to know that having one lookup table isn’t the best way to go. From a performance standpoint, why is that? Consider the following example:

you have a list of schools in cities. There can me more than one school in a given city.
So you have a junction table schoolCities between the two. Now consider a list of businesses. there can be more than one business in each city. So you have a junction table businessCities. The question really is: why is it so bad if you just use one cities table and make a junction table for schools and business versus having each table school and business its own copy of the cities table?

Answer 1

What you’re describing isn’t the “one true lookup table;” a Cities table in your example sounds like a good normalizing idea. The “one true lookup table” would be more like

CREATE TABLE TheOne (
    LookupType varchar(20) NOT NULL -- City, color, shoe size...?
    , LookupValue varchar(1000) NOT NULL -- how big does it have to be?
    , CONSTRAINT pk_TheOne PRIMARY KEY (LookupType, LookupValue)
)

and you might have values:

'City', 'Philadelphia'
'City', 'St. Petersburg'
'City', 'Paris'
'State', 'Pennsylvania'
'State', 'Florida'
'Country', 'United States'
'Country', 'France'
'Brand', 'Lucky'
'Brand', 'Diesel'
'Brand', 'Old Navy'

and so on. Pure evil.

A Cities table would probably associate a city with a State or other parent geographical region, since there can be many different cities with the same name (Paris, Lima, Levittown, etc).