Как определить пользовательский тип данных с адресуемыми членами?

Question

У меня есть необычная ситуация для моделирования в базе данных MS SQL Server:первичный ключ таблицы — это многосегментный «естественный» ключ, состоящий из 5 внешних ключей (фиксированных размеров).

Я хотел бы иметь возможность определить определяемый пользователем тип данных для реализации структуры данных на основе примитива CHAR(8) таким образом, чтобы к элементам можно было обращаться как к отдельным полям.

Например (в плохом псевдокоде):

UDT seggy
(
    seg1 char(2),
    seg2 char(1),
    seg3 char(1),
    seg4 char(2),
    seg5 char(2)
)

create table yotable
(
    pkfield seggy NOT NULL,
    etc varchar(14),   --whatever etc.
)
with pkfield as the primary key,
and also with seg1 as a foreign key to tableseg1,
and also with seg2 as a foreign key to tableseg2,
and so on

и затем иметь возможность делать такие вещи:

insert into yotable (pkfield, etc) values ('abcdefgh','whatever')
select * from yotable where seg2 = 'c'
insert into yotable (seg1,seg2,seg3,seg4,seg5,etc)
    values ('ab','c','d','ef','gh', 'whatever')

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

Судя по всему, мой гугл-фу сегодня слаб, буду благодарен за любые ссылки/подсказки!

Альтернативное название:как имитировать поля «наложения» в SQL SERVER?

Предполагается/предпочтительно MS SQL SERVER 2005 или более поздней версии.

Answer 1

Вы можете определить UDT CLR, имеющий нужную структуру, но (1) вы не сможете хранить внешние ключи (внешние ключи должны находиться на уровне столбца, а не поля в UDT в столбце); и (2) реализовать CLR UDT непросто (по крайней мере, по сравнению с тем, что находится в вашем псевдокоде).Кроме того, судя по вашему описанию, похоже, что на самом деле это отдельные столбцы семантически, и то, что вы ищете, — это просто ярлык для удобства;В любом случае, IMO, UDT, вероятно, не лучший подход в этом сценарии.

Я бы предложил сохранить отдельные столбцы, но создать либо представление со столбцом, объединяющим поля, либо вычисляемый столбец в таблице, который делает то же самое.Это позволит осуществлять поиск с использованием как комбинированной, так и раздельной записи.Затем вы можете использовать триггер INSTEAD OF, чтобы разложить вставку/обновление объединенного столбца на составные части.