mysql - 索引国家、州、城市的难度

Question

我计划通过将 Locations 表中的 locationID 提供给 User 表中的每个用户来规范化，而不是为共享同一位置的多个用户输入重复的用户位置，这样我就不必重复输入 Country、State、City在用户表中，所以我节省了磁盘空间。 (美国，康涅狄格州，伍德黑文)

在几个用户说第 12 个用户可以输入 USA,NY, Albany 之后，这个条目被输入到 Locations Table 的第 12 行。当用户输入他的位置信息(国家、州、城市)时，我需要在输入新记录之前检查位置表以查看该记录是否存在。问题是您无法为 State 和 City 列编制索引，因为它们与国家(分别为 Afghanistan 、Alabama、Azirben、Country、State 和 City)不匹配。

是否有一种有效的方法可以对州和城市进行排序，使其与按字母顺序索引的国家/地区名称保持一致(我希望在阿富汗以 A 开头的州和以 A 开头的城市将阿富汗国家列为第一行依此类推，假设阿富汗是国家列表中的第一个国家。

我相信即使具有单独 Locations 表的规范化方法节省了磁盘空间，但搜索记录的时间，如果不在 Locations 表中则插入，然后在用户表中插入 LocationsID 的时间成本更高。我的断言正确吗？

Answer 1

这是数据库规范化的一个典型陷阱:规范化只是为了空间。

空间很便宜。

从函数依赖的角度考虑:元组 (Country, State, City) 应该是函数依赖，但您没有任何依赖于它的信息，也没有它的组件(至少您没有告诉我们)。或者，您可以具有某些功能依赖项，例如 State->Country 或 City->Coutry,State(但您已经知道全局数据库不是这种情况)。

您同样可以将它作为单个属性“Country;State;City”，它不会影响您的设计(从功能依赖的角度来看；从搜索数据的角度来看它会影响)。

换句话说，如果您有任何特定于元组(国家、州、城市)的信息，或者您有想要在元组本身内强制执行的功能依赖性，您可能希望规范化此表。

如果你不这样做，那么不要为了空间而对其进行标准化。空间从来都不是标准化背后的主要动机(更新/插入/删除异常是主要原因)。

这样说吧。你会为了节省空间而规范化一个人的名字和姓氏吗？

如果你还想这样做，那么不用担心索引如何对数据进行排序。那不应该是你的担心。您可以在(国家、州、城市)上创建基于树的索引——默认情况下——然后您可以搜索给定的国家或国家/地区，或国家/地区/州/城市(您始终可以使用基于树的索引中的前缀)。您可以在具有任意属性组合的表上创建任意数量的索引。但这会占用空间，并会减慢插入速度，但我怀疑无论如何该表中的内容都不多。

我的建议是，不要规范化这些数据。

--伤害