Как определить пользовательский тип данных с адресуемыми членами? - PullRequest
1 голос
/ 17 декабря 2008

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

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

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

Альтернативный заголовок: как смоделировать 'оверлейные' поля в SQL SERVER?

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

1 Ответ

1 голос
/ 17 декабря 2008

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

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

...