Come definire un tipo di dati definito dall'utente con i membri indirizzabili?

Question

Ho una situazione insolita per modellare in un database MS SQL Server: la chiave primaria di una tabella è la chiave di un multi-segmento 'naturale' composta da 5 chiavi esterne (di dimensioni fisse)

.

Vorrei poter definire un tipo di dati definito dall'utente per implementare la struttura di dati basata su un CHAR (8) primitiva in modo tale che gli elementi sono indirizzabili come singoli campi.

Per esempio (in cattive pseudocodice):

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

e poi essere in grado di fare le cose in questo modo:

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

Finora tutto quello che ho trovato è questo CodeProject articolo che fa non va abbastanza lontano o fornire link per ulteriori informazioni, e questo rudimentale MSDN link .

A quanto pare il mio google-fu è questa sera debole, tutti i link / suggerimenti molto apprezzato!

titolo alternativo:? Come simulare 'overlay' campi in SQL Server

MS SQL Server 2005 o versioni successive assunto / preferito.

Answer 1

È possibile definire un UDT CLR che ha la struttura che si desidera, ma (1) non sarà in grado di tenere le chiavi esterne (chiavi esterne devono essere a livello di colonna, non è un campo in un UDT in un colonna), e (2) non è banale per implementare un UDT CLR (almeno rispetto a ciò che è nel vostro pseudocodice). Inoltre, dalla tua descrizione, sembra che realmente sono colonne separate semanticamente, e ciò che stai cercando è solo una scorciatoia per convenienza; IMO un UDT probabilmente non è l'approccio migliore in questo scenario in ogni caso.

suggerirei mantenendo le colonne separate, ma creare sia una vista che ha una colonna che concatena i campi insieme, o una colonna calcolata nella tabella che fa la stessa. Ciò consentirà la ricerca utilizzando la notazione combinato o separato. È quindi possibile utilizzare un trigger INSTEAD OF per decomporre un inserimento / aggiornamento sulla colonna combinato nelle parti che lo compongono.