2010-09-09 24 views
0

地理實體是:大陸,國家,省,城市,鄰里。默認情況下,大洲,國家和城市將始終存在。省是可選的,因爲並非所有國家都有州/省。並且鄰里數據需要一定的時間才能找到,所以它是數據進來時的負載。位置/品牌/公司 - 模式設計路線?

其他實體: 郵編(映射到城市(必填)和鄰居(可選))。 經緯度(映射到城市,鄰里,本地商業) 公司,品牌,本地商業(公司通過總部地區和公司地點實地映射到城市品牌地圖通過當地商家。城市和當地商店根據需要映射到城市和鄰居可選,也需要將公司,品牌和本地商店關聯到國家和全球層面。爲此制定模式1)我可以捕獲所有關係,2)連接都很小,因爲有大量的其他表和實時饋送數據 - 這意味着我需要保持關係denormialized? 3)確保數據更新很容易插入新數據,如果創建了錯誤的關係,很容易改變它?

那麼每個實體都應該獲得自己的故事還是將它們全部扔進1-2個表格?除lat/longitue以外,這些實體中的每一個都可以在網站上進行搜索,並且是分析過濾器指標的一部分。

編輯:我必須對不同級別的連接與地點的所有系統對象添加這是一個「地理」基於社交網絡,連接人與他們的地方城市,因此着重強調。

回答

1

我會從一個規範化的數據庫模式開始,使用它來讓你的思維直線化。最初對標準化數據庫進行一些實驗,根據需要添加索引以執行查詢。作爲最後的手段去標準化。

在這裏,你似乎有公司,品牌和LocalBusiness實體恰當的定義,你一定需要這些表。

然後你似乎有一個位置,這是一個部分指定的地理概念。看起來Location與LocalBusiness是一對多的關係 - 可以(很少,但實際上可以)有許多商戶,它們使用完全相同的ZipCode或Lat/Long。

所以我有很多爲空的領域,包括CityId,NeighbourhoodId,郵編,緯度/長一個位置的實體。我認爲只有CityId和Zip不能爲空。

城市和周邊需要被巧妙地處理 - 我想在你的位置的關鍵havea到一個更復雜的實體。因此CityId將我們帶到包括省,州等在內的城市。鄰居需要去鄰居。我懷疑鄰里是一個複雜的概念。我住在South JavaVille,這是JavaVille的附屬地區,它是OobleDon倫敦自治市的一部分,也是Middlesex的行政區域。

+0

那麼標準化模式的問題是多少呢?我沒有提到公司屬於屬於一個行業的子行業的其他關係,這個行業屬於另一個有其他不同兒童和大孩子數據流的行業。由於系統中的所有內容都可以通過自動提示功能進行報告,搜索和使用,因此問題可能出在許多不同的查找表上,那麼我應該在這裏爲每個關係創建。那麼這些查詢表將會有很多呢? – kino 2010-09-09 07:33:08

+0

我正在模擬「Sector-Industry-Company-Brand-Local store」實體的位置。因此,從歐洲大陸,國家,(州/省),城市,(鄰居/地區)+郵編縮放位置。緯度/經度僅用於以後的地理編碼目的。我不會接觸行政區,地區或者數字。如果每個國家都不同,那麼建立和連接每一個信息都是太多了,因爲這個模式需要對所有國家都是全球性的。 – kino 2010-09-09 07:36:47