database - 一种真正的查找表的优点与缺点

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。

2个月前关闭。



Improve this question




因此，我已经读够了，知道拥有一个查找表并不是最好的方法。从性能的角度来看，这是为什么呢？考虑以下示例:

您有城市中的学校列表。在一个给定的城市中，我可以有不止一所学校。
因此，您在两者之间有一个联结表schoolCities。现在考虑一个企业列表。每个城市中可以有多个业务。因此，您有一个连接表businessCities。问题的实质是:为什么只使用一个city表并为学校和企业创建联结表，而不是让每个表学校和企业拥有自己的city表副本，为什么这么糟糕？

最佳答案

您要描述的不是“一个真正的查询表”；而是您的示例中的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'

等等。纯粹的邪恶。

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