Mehrere Eingabetypen für ein UDT

Ich weiß nicht, ob das, was ich tun möchte, möglich ist oder nicht, und ich bin nur neugierig.

Ich habe eine benutzerdefinierte Art von sagen MyType, die ein TINYINT zusammen mit einer REGEL ist, die besagt, dass der zulässige Wert zwischen 0 und 3 liegen muss.

-- Existing UDT & Rule which work CREATE TYPE [MySchema].[MyTypes] FROM [TINYINT] CREATE RULE [MySchema].[MyTypes_Rule] AS @Range BETWEEN 0 AND 3 sp_bindrule 'MySchema.MyTypes_Rule', 'MySchema.MyTypes' 

Was würde ich gerne wissen, wäre es möglich, eine zusätzliche Regel / functionalität hinzuzufügen, die mir erlauben würde, eine zusätzliche Regel zu erstellen, die einen NVARCHAR-Wert nehmen würde und wenn es in diesem Bereich den entsprechenden TINYINT-Wert umwandelt.

 CREATE RULE [MySchema].[MyTypes_NVARCHAR_Rule1] AS @InValues IN (N'N', N'A', N'B', N'C') CREATE RULE [MySchema].[MyTypes_NVARCHAR_Rule1] AS @InValues IN (N'No Choice', N'Choice A', N'Choice B', N'Choice C') 

Und dann eine Art von Umwandlung von 'Choice A' oder 'A' auf einen Wert von 1, 'Choice B' oder 'B' auf einen Wert von 2, etc, etc, etc.

Das folgende Skript wäre ähnlich der functionalität, die ich tun möchte, wo ein String in einen zulässigen Wert umgewandelt wird.

 CREATE TABLE [MyTable] ( [MyValue] BIT, [Description] NVARCHAR(20) ) GO INSERT INTO [MyTable] ( [MyValue], [Description] ) SELECT 0, 'Enterered as 0' -- false UNION SELECT 1, 'Enterered as 1' -- true UNION SELECT CAST(0 AS BIT), 'Enterered as CAST(0 AS BIT)' -- false UNION SELECT CAST(1 AS BIT), 'Enterered as CAST(1 AS BIT)' -- true UNION SELECT CAST('false' AS BIT), 'Enterered as CAST(''false'' AS BIT)' -- false UNION SELECT CAST('true' AS BIT), 'Enterered as CAST(''true'' AS BIT)' -- true 

Nein, so ist das nicht in einfachem T-SQL möglich.

Du könntest eine CLR Benutzerdefinierte function erstellen, die ein sql_variant hat, und dann testing Sie das Testen innerhalb dieses, aber ich würde die Notwendigkeit für sie in Frage stellen. Normalerweise möchten Sie diese Art von Übersetzung in dem Code, der in Ihrer Benutzeroberfläche ausgeführt wird, so dass Sie bereit sind mit einem festen datatyp durch die time, die Sie auf Ihre Business-Logik-Schicht, geschweige denn Ihre database.

Übrigens wird CREATE RULE abgelehnt – und wurde auf der 'diese function wird in einer zukünftigen Version' Status für eine lange time entfernt werden. Bisher habe ich keine Alternativen gesehen, die Ihnen CHECK würden, eine CHECK Einschränkung für benutzerdefinierte Typen zu definieren. Das ist vielleicht ein Grund des Grundes, warum es noch nicht veraltet ist.