Question

我正在开发一个特定于位置的应用程序 - 将其视为商店定位器，其中商店所有者输入其地址信息，而其他用户只能看到某个范围内的附近商店。然而，在某种意义上它不需要确切的位置，只需要城市/州（很奇怪，我知道）。我已经考虑了存储位置的模式，并决定了这个。

地点

id                      -- int
formatted_address       -- varchar(200)
is_point_of_interest    -- bool
name                    -- varchar(100) -- NULL
street_number           -- varchar(10)  -- NULL
street                  -- varchar(40)  -- NULL
city                    -- varchar(40)
state                   -- varchar(40)
state_code              -- varchar(3)
postal_code             -- varchar(10)
country                 -- varchar(40)
country_code            -- varchar(3)
latitude                -- float(10,6)
longitude               -- float(10,6)
last_updated_at         -- timestamp

以下是有关该应用程序的一些注意事项：

我想为国际地点敞开大门
我计划使用地理编码服务来搜索并验证商店所有者指定的位置
我真的只需要lat / lon，但显示商店信息需要其他数据
formatted_address字段将包含完全格式化的地址 - 例如，Giants Stadium，50 NJ-120，East Rutherford，NJ 07073，USA - 以便于搜索存储的位置
可能会有很多重复字段，因为每行可能具有不同的粒度级别 - 例如，123 Main Street, City, State 12345与Main Street, City, State 12345不同，因为其中一个具有指定的街道号码其他不

我知道架构不是很规范化，但我也认为不再需要对其进行规范化，因为位置非常复杂，这就是为什么我依赖于稳定的地理编码服务（google）。此外，我计划允许自由格式文本输入/搜索，因此不需要任何下拉列表。

考虑到我提到的内容，是否有人看到任何错误或有任何改进？我可以看到这张桌子变得越来越大了。

Answer 1

既然你说“我真的只需要lat / lon”，我鼓励你使用2个1：1关系的表格。

在许多（大多数？）情况下，将会缓存更多的lat / lon对，从而加速你的主力。如果您需要其他信息，请在需要时获取。

简短形式：不要强制DB通过IO和RAM移动您不需要的数据

此外，这样的架构可以保持大门进一步自然扩展：链接其他信息可以通过添加其他表而不是更改现有表来完成。我认为这对你的软件质量来说是件好事。

Answer 2

我不这么认为。这是我的两分钟概要：

这非常规范化。至少city - ＆gt; country应该移出到另一个表（并从那里标准化）。我相信邮政编码可以跨越城市边界（或者我非常错误地记错了）;我不知道这样一个跨越国界的城市。

formatted_address是一个“优化”，可能应该是一个计算字段：也就是说，重新创建它的所有数据应该存在其他地方。（这意味着它现在不需要担心。）

快乐的设计。

简单的“更规范化”形式只是执行上述建议：

LOCATIONS
location_id             -- int
is_point_of_interest    -- bool
name                    -- varchar(100) -- NULL
street_number           -- varchar(10)  -- NULL
street                  -- varchar(40)  -- NULL
city_id                 -- int
postal_code             -- varchar(10)
latitude                -- float(10,6)
longitude               -- float(10,6)
last_updated_at         -- timestamp

CITIES
city_id                 
name                    -- varchar
-- similarly, the following should be normalized to STATES and COUNTRIES
state                   -- varchar(40)
state_code              -- varchar(3)
country                 -- varchar(40)
country_code            -- varchar(3)

当然，CITIES可以进一步规范化，因此可以一个POSTALS表：我对邮政编码或应用程序域知之甚少。 postal_code作为隐含的复合代理 - FK的一部分，因此它不是超级可怕的。但是，将其移动到单独的表中可以轻松地允许验证和完整性约束。

编辑：规范化POSTALs表格是最好的，因为只有非常少数的邮政编码对某个城市有效：我不确定邮政编码和城市之间的关系，但是，所以我不建议怎么做。也许看看现有的架构使用？

这是一个很好的位置数据库架构

2 个答案: