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
))

存在层次结构的地方，类似于 状态 - ＆gt;区 - ＆gt; Taluk - ＆gt;村庄 - ＆gt; Street1 - ＆gt; STREET2

保留一个单独的表来存储层次结构不是一个好主意，这样我们就可以避免重复数据。以下是

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'将如下所示

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引用了LocationDemo的LocationID。

Answer 1

虽然您提出的解决方案比您描述的扁平化解决方案更具动态性，但在这种情况下，我不会使用完全动态的模式来定位。添加分层处理是不没有充分理由要做的事情，因为它会在以后使您的数据库查询复杂化并限制您的性能优化备选方案（包含CTE的视图无法编入索引，您需要视图才能合理地使用此您的申请数据。）

如果您正在谈论低容量系统或存储的地址数量很少的系统，您可以使用动态地址元素路由，但考虑到没有大多数地址，逻辑上不存在任何一个地址的事实位置元素我再次说它有点矫枉过正。

寻求更加规范化的路线而不会过火。考虑从Address，District表和FK等对该表创建一个State表和FK ......

使用hierarchyid存储客户的地址

1 个答案: