所以我已经阅读了足够多的内容，知道拥有一个查找表并不是最好的方法。从性能的角度来看，这是为什么呢？考虑以下示例：
你有一个城市的学校列表。在一个给定的城市里，我可以有不止一所学校。 因此，您在两者之间有一个连接表 schoolCities。现在考虑一个企业列表。每个城市可以有不止一个企业。所以你有一个连接表businessCities。真正的问题是：如果你只使用一个城市表并为学校和企业制作一个连接表，而不是让每个学校和企业都有自己的城市表副本，为什么会如此糟糕？
【问题讨论】：
实际上，OTLT 设计可能有一些优势（我现在真的感觉脑袋要爆炸了）。
我见过的运行良好的模型应该是这样的。
LookupId、LookupTypeId、LanguageId、Description（显示的数据）
然后你在存储过程中的参数。将只是 typeid （获取所有类型）。如果您只需要转换特定类型的 Id，则只需传递 LookupId。将设置默认语言（在我们的例子中，它是英语）。这是一种以多语言格式显示网站显示数据的好方法。
我们实际上使用了 Match.com，并且每天在它上支持数百万用户非常好。我们实际上只是在网络启动时缓存了查找。这是一个非常有效的系统。最大的优势是我们可以直接将数据推送到生产环境，而不是添加/更改大表模式。
在我看来，只要您只处理小的下拉数据等（典型的应用程序显示内容），它就可以在性能、维护和易于添加新内容方面提供很大的优势类型。
我知道这是一种不受欢迎的方法。但是，它在正确的场景中运行良好，如果您对它的使用受到限制且有纪律。
只有我的 2 美分。我敢肯定，我会因为在这个话题上采取不受欢迎的立场而被扣分。
【讨论】：
您所描述的不是“一个真正的查找表”；您示例中的 Cities 表听起来是一个很好的规范化想法。 “一个真正的查找表”会更像
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)
)
你可能有价值观：
'City', 'Philadelphia'
'City', 'St. Petersburg'
'City', 'Paris'
'State', 'Pennsylvania'
'State', 'Florida'
'Country', 'United States'
'Country', 'France'
'Brand', 'Lucky'
'Brand', 'Diesel'
'Brand', 'Old Navy'
等等。纯粹的邪恶。
Cities 表可能会将城市与州或其他父地理区域相关联，因为可能有许多不同的城市具有相同的名称（Paris、Lima、Levittown 等）。
【讨论】：