0

我有一个名为“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
))

存在层次结构的地方，类似于 州 --> 区 --> Taluk --> 村 --> Street1 --> 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
))

和LocationIDAddressDemo 对LocationIDLocationDemo 的引用。

4

1 回答 1

1

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

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

走一条更规范的路线，而不会过火。考虑从 Address、District 表和 FK 等创建一个 State 表和一个 FK 到该表...

于 2011-08-28T01:34:50.943 回答