使用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等...