Jakie są różne sposoby obsługi wyliczeń na serwerze SQL?

Question

Obecnie zdefiniować listę stałych (głównie te odpowiadają wyliczeń mamy zdefiniowane w warstwie biznesowej) w górnej części procedury przechowywanej tak:

DECLARE @COLOR_RED INT = 1 
DECLARE @COLOR_GREEN INT = 2 
DECLARE @COLOR_BLUE INT = 3 

Ale te często są powtarzane dla wielu procedur przechowywanych tak jest dużo duplikacji.

Inną techniką, której używam, jeśli procedura wymaga tylko jednej lub dwóch stałych, jest przekazanie ich jako parametrów do procedury przechowywanej. (używając tej samej konwencji wielkich liter dla stałych wartości). W ten sposób jestem pewien, że wartości w warstwie biznesowej i warstwie danych są spójne. Ta metoda nie jest dobra dla wielu wartości.

Jakie są pozostałe opcje?

Używam programu SQL Server 2008 i C#, jeśli ma to jakiekolwiek znaczenie.

Aktualizacja Ponieważ używam .Net jest jakiś sposób, że typy zdefiniowane przez użytkownika (CLR) mogą pomóc?

Answer 1

mogę zaproponować dwa różne podejścia:

1) określa tabelę wyliczenie z kolumną tinyint tożsamości jako klucz podstawowy, a wartość enum jako unikalnego indeksu; na przykład

CREATE TABLE [dbo].[Market](
     [MarketId] [smallint] IDENTITY(1,1) NOT NULL, 
     [MarketName] [varchar](32) COLLATE Latin1_General_CS_AS NOT NULL, 
CONSTRAINT [PK_Market] PRIMARY KEY CLUSTERED 
(
     [MarketId] ASC 
) ON [PRIMARY] 
) ON [PRIMARY] 

wówczas:

• Czy aplikacja załadować wyliczanie do mapowania wartości klucza podstawowego na rozruchu (zakładając ten pozostanie na stałym poziomie).
• Definiowanie funkcji translacji wartości wyliczeniowych na wartości kluczy podstawowych. Ta funkcja może być następnie używana przez przechowywane procesy wstawiające dane do innych tabel w celu ustalenia klucza obcego do tabeli wyliczeniowej.

2) Zgodnie z (1), ale zdefiniuj każdą wartość klucza podstawowego, aby była potęgą 2. Dzięki temu inna tabela może odwoływać się do wielu wartości wyliczeniowych bezpośrednio, bez potrzeby tworzenia dodatkowej tabeli powiązań. Załóżmy na przykład, że definiujesz tabelę wyliczania kolorów z wartościami: {1, "czerwony"}, {2, "niebieski"}, {4, "zielony"}. Inna tabela może odwoływać się do wartości czerwonej i zielonej, włączając klucz obcy 5 (to jest bitową wartość OR wynoszącą 1 i 4).

Answer 2

Funkcja definiowania użytkownika skalarnego? Nie idealne, ale funkcjonalny ...

CREATE FUNCTION dbo.ufnRGB (
    @Colour varchar(20) 
) 
RETURNS int 
AS 
BEGIN 
    DECLARE @key int 

    IF @Colour = 'BLue' 
     SET @key = 1 
    ELSE IF @Colour = 'Red' 
     SET @key = 2 
    ELSE IF @Colour = 'Green' 
     SET @key = 3 

    RETURN @KEy 
END 

Answer 3

nie podoba mi się pomysł definiowania jakie są skutecznie stałe dla procedur składowanych w wielu miejscach - to wydaje się jak koszmar konserwacyjnych i jest podatny na błędy (literówki etc). W rzeczywistości nie widzę wielu okoliczności, kiedy musiałbyś coś takiego zrobić?

Zdecydowanie zachowałbym wszystkie definicje wyliczeń w jednym miejscu - w klasach C#. Jeśli to oznacza konieczność przekazywania ich do swoich procedur za każdym razem, niech tak będzie. Przynajmniej w ten sposób są one zdefiniowane tylko w jednym miejscu.

Aby to ułatwić, można napisać kilka metod pomocniczych do wywoływania procedur, które automatycznie przekazują parametry wyliczeniowe dla Ciebie. Dlatego wywołujesz metodę pomocniczą tylko z nazwą procedury i parametrami "zmiennymi", a następnie metoda pomocnicza dodaje dla ciebie pozostałe parametry wyliczania.

Answer 4

To może być kontrowersyjne: moje podejście nie używa wyliczeń w T-SQL. T-SQL nie jest tak naprawdę zaprojektowany w sposób, który czyni enum użyteczne, tak jak są w innych językach. Dla mnie, w T_SQL, oni po prostu dodają wysiłku i złożoności bez korzyści widzianych gdzie indziej.

Answer 5

Co powiesz na używanie funkcji skalarnej jako stałej. Konwencja nazewnictwa spowodowałaby, że ich użycie było bliskie wyliczeniom:

CREATE FUNCTION COLOR_RED() 
RETURNS INT 
AS 
BEGIN 
    RETURN 1 
END 

CREATE FUNCTION COLOR_GREEN() 
RETURNS INT 
AS 
BEGIN 
    RETURN 2 
END 

...