使用HIERARCHYID存儲客戶的地址

Question

我有一個名爲「AddressDemo」與以下領域客戶的存儲地址

CREATE TABLE [dbo].[AddressDemo](
[AddressID] [int] IDENTITY(1,1) NOT NULL, 
[State] [nvarchar](50) NULL, 
[District] [nvarchar](50) NULL, 
[Taluk] [nvarchar](50) NULL, 
[Village] [nvarchar](50) NULL, 
[Street1] [nvarchar](50) NULL, 
[Street2] [nvarchar](50) NULL, 
[Phone] [nvarchar](50) NULL, 
[Mobile] [nvarchar](50) NULL, 
[Email] [nvarchar](50) NULL, 
CONSTRAINT [PK_AddressDemo] PRIMARY KEY CLUSTERED 
(
    [AddressID] ASC 
)) 

哪裏有層次存在，這是類似於 表，州 - >區 - >塔魯克 - >村 - >街道1 - >街道2

是不是一個好主意，保留一個單獨的表來存儲層次結構，以便我們可以避免重複數據。該如何以下

CREATE TABLE [dbo].[LocationDemo](
[LocationID] [int] IDENTITY(1,1) NOT NULL, 
[LocationNodeID] [hierarchyid] NULL, 
[Location] [nvarchar](50) NULL, 
CONSTRAINT [PK_LocationDemo] PRIMARY KEY CLUSTERED 
(
    [LocationID] ASC 
)) 

所以 'AddressDemo' 看起來像LocationDemo以下

CREATE TABLE [dbo].[AddressDemo](
[AddressID] [int] IDENTITY(1,1) NOT NULL, 
[LocationID] [int] NULL, 
[Phone] [nvarchar](50) NULL, 
[Mobile] [nvarchar](50) NULL, 
[Email] [nvarchar](50) NULL, 
CONSTRAINT [PK_AddressDemo] PRIMARY KEY CLUSTERED 
(
    [AddressID] ASC 
)) 

的AddressDemo參考

和LocationID到LocationID。

Answer 1

雖然您提出的解決方案比您所描述的扁平化解決方案更具動態性，但在此情況下，我不會採用完全動態的架構來處理位置。添加分層處理是而不是沒有充分的理由要做，因爲它稍後會使數據庫查詢變得複雜，並限制性能優化的選擇（包含CTE的視圖不能編入索引，並且您需要視圖合理地使用此應用程序的數據） 。

如果您正在討論低容量系統或存儲地址數量較少的系統，您可以使用動態地址元素路由進行播放，但考慮到如果沒有大多數系統在邏輯上不存在任何地址的位置元素我會再次說這是過度殺傷。

尋找更加規範化的路線，不會過度。考慮制定國表和FK到該表從地址，分區表和FK等...