這是一個很好的位置數據庫模式

我正在處理一個特定位置的應用程序 - 將其視爲一個商店定位器，其中商店所有者輸入他們的地址信息，其他用戶只能在一定範圍內看到附近的商店。然而，從某種意義上說，這是有點不同的，因爲不需要確切的位置，只需要城市/州（我知道這很奇怪）。我曾考慮過用於存儲位置的模式，並決定使用這種模式。這是一個很好的位置數據庫模式

位置

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，bu t其他數據對於顯示商店信息是必需的
formatted_address字段將包含完全格式化的地址 - 例如，美國新澤西州07073東盧瑟福的50 NJ-120巨人體育場 - 以允許更容易地搜索存儲位置
將有可能出現很多重複的領域，因爲每行可有粒度的不同級別 - 例如，123 Main Street, City, State 12345是Main Street, City, State 12345不同，因爲一個具有指定的街道號碼和其他沒有

我知道模式不是很規範化，但我也沒有看到需要對它進行標準化，因爲位置非常複雜，這就是爲什麼我依賴穩定的地理編碼服務（谷歌）。另外，我打算允許自由形式的文本輸入/搜索，因此不需要任何下拉列表。

有沒有人看到任何錯誤或有任何改進，考慮到我所提到的？我可以看到這張桌子越來越大。

來源

2012-01-06 BDuelz

請不要在帖子上簽名。 – 2012-01-06 20:06:46

郵政編碼唯一標識一個城市，州/省和國家。我會刪除這些字段，並將它們製作成自己的表格。爲每個郵政編碼指定一個代理鍵唯一整數ID，以防兩個國家共享一個代碼。 – Yuck 2012-01-06 20:07:53

登錄信息？你什麼意思？ – BDuelz 2012-01-06 20:07:56

我不這麼認爲。這是我的兩分鐘簡介：

這非常嚴重的規範化。至少city - >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)

當然，城市可以進一步正常化，等可能一個POSTALS表：我不對郵政編碼或應用領域知之甚少。 postal_code充當隱式複合代理-FK的一部分，所以它不是超級可怕的，因爲它在那裏。但是，將其移入單獨的表格可能會輕鬆地驗證和完整性限制。

編輯：進行歸一化POSTALs表將是最好的，因爲只有郵遞區號非常samll號的有效期爲一個給定的城市：我不知道郵政編碼和城市之間的關係，雖然如此，我不能推薦如何做到這一點。也許看看現有的模式？

來源

2012-01-06 20:22:44

我明白它的標準化程度很差，但是我覺得正常化所有東西都會讓我頭痛，因爲我上面提到的原因 - 非常複雜。此外，雖然不是一個主要問題，因爲這張桌子可能會變得相當大，所有這些連接都會受到傷害...... – BDuelz 2012-01-06 20:29:38

**沒有。 No No。**頭痛將來自*不正常化* - 很容易*將標準化的一組表格變成一個非標準化的表格。至於性能：**除非有性能測試案例**，否則不存在性能問題。考慮到RDMBS *已經被設計用於這種「加入」行爲，並且對於痕跡*這樣做**的確非常好，意味着，如果有的話，您可能會減慢更多的頁面閱讀速度！ – 2012-01-06 20:31:24

好吧......如果它不是太多，你能提出一個模式，只是你覺得有必要的表格嗎？ – BDuelz 2012-01-06 20:32:57

既然你說「我真的只需要經緯度」，我鼓勵你使用兩張1：1的關係表。

在許多（大多數？）情況下，很多經緯度對將被緩存，加快了你的主力。如果您需要附加信息，請在需要時獲取。

簡稱：不要強迫DB動你不通過IO需要的數據和RAM

另外，這種模式會保持你的門打開進一步的自然擴展：通過添加鏈接等信息可以做到其他表格而不是改變現有表格。我認爲這對你的軟件質量是一件好事。

來源

2012-01-06 20:13:51

對不起，也許我應該更清楚。雖然緯度/經度對距離計算很重要，但其他數據對於顯示商店信息是必需的。 – BDuelz 2012-01-06 20:17:13

我不完全確定這兩張表會是什麼，如果有1：1的關係，我不明白它的意義。你可以解釋嗎？ – BDuelz 2012-01-06 20:18:04

同樣的問題：你做了大部分關於緯度/經度的工作嗎？如果是，請將它們分開以便從緩存中獲利。如果沒有，將它們合併（即按照您的問題建議使用） – 2012-01-06 20:18:39

這是一個很好的位置數據庫模式

回答

相關問題