Question

所以我已经阅读了足够的知道，有一个查找表不是最好的方法。从性能的角度来看，为什么呢？请考虑以下示例：

你有一份城市学校名单。在给定的城市中，我可以有多所学校。所以你们两个之间有一个联合表schoolCities。现在考虑一个企业列表。每个城市可以有多个企业。所以你有一个联结表businessCities。问题的确如此：如果您只使用一个城市表并为学校和企业建立联结表而不是让每个表学校和企业都拥有城市表的副本，为什么会这么糟糕？

Answer 1

实际上，OTLT设计可能会有一些优势（我现在感觉头部爆炸）。

我见过的模型非常好用就是这样。

LookupId，LookupTypeId，LanguageId，Description（显示的数据）

然后你的params在存储过程中。将只是typeid（获得所有类型）。如果您只需要转换特定类型的Id，则只需传递LookupId即可。将设置默认语言（在我们的例子中，它是英语）。这是以多语言格式为网站的显示数据设置外观的好方法。

我们实际上将它用作Match.com，每天支持数百万用户。我们确实在Web启动时缓存了查找。这是一个非常有效的系统。最大的优势是我们可以简单地将数据推送到生产而不是大表模式添加/更改。

我看待它的方式，只要你只处理小的下拉数据等（典型的应用程序显示东西），它在性能，维护和添加新的容易性方面可以提供很大的优势类型。

我知道这是一种不受欢迎的方法。但是，它确实在正确的场景中运作良好，如果你对它的使用有限且受到纪律处分。

只需2美分。我确定我会扣除积分或者其他任何因为这个话题不受欢迎的立场。

Answer 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'

等等。纯粹的邪恶。

城市表可能会将城市与州或其他父地理区域相关联，因为可能有许多不同的城市具有相同的名称（巴黎，利马，莱维敦等）。

一个真正的查找表优点与缺点

2 个答案: