Использовать иерархию для хранения адреса клиента - PullRequest
Новая
       11

Использовать иерархию для хранения адреса клиента

0 голосов
/ 28 августа 2011

У меня есть таблица с именем 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' будет выглядеть следующим образом 

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

и LocationID для AddressDemo ссылаются на LocationID для LocationDemo.

1 Ответ

1 голос
/ 28 августа 2011

Хотя ваше предлагаемое решение более динамично, чем описанное вами плоское решение, в этом случае я бы не использовал полностью динамическую схему для местоположений. Добавление иерархической обработки - это , а не , что нужно делать без веской причины, поскольку в дальнейшем это усложняет запросы к вашей базе данных и ограничивает альтернативы оптимизации производительности (представления, содержащие CTE, не могут быть проиндексированы, и вам потребуются представления, чтобы разумно использовать эти данные. по вашей заявке).

Если вы говорите о маломасштабной системе или системе, в которой количество сохраняемых адресов мало, вы можете поиграть с маршрутом динамического элемента адреса, но учитывая тот факт, что ни один адрес не существовал бы логически без большинства элементы локации, я бы опять сказал, что это излишне.

Перейти на более нормализованный маршрут, не выходя за борт. Подумайте о создании таблицы состояний и FK для этой таблицы из Address, таблицы District и FK и т. Д. ...

...