Как использовать перечисления в TSQL без магического номера жесткого кодирования по всем моим SQL-скриптам/procs?

У нас есть перечисления в нашем коде С#:

public enum JobStatus
{        
  Ready = 0,      
  Running = 1,        
  Cancelling = 2,
}

Эти значения также сохраняются в полях базы данных, и у нас есть лоты TSQL (в основном хранимые procs, а также некоторые пакеты и SSIS), которые также обрабатывают данные:

SELECT TOP 1 @JobSID = JobSID
FROM Job 
WHERE Status = 0 /* JobStatus.Ready */
ORDER BY SubmitDate ASC

CREATE TABLE ImportCrossEffect(
    /* lots deleted */      
    Source tinyint 
      DEFAULT 1 NOT NULL -- 0: Unknown (default), 1:Imported, 2:Keyed
)

Как избежать жесткого кодирования "магических чисел" в TSQL?
Как удалить риск перечислений, не соответствующих сторонам С# и TSQL?

(Я включил тег С#, так как я хотел бы, чтобы решение, которое "одним источником" определяло перечисления на сторонах С# и TSQL)

Обновление:

У нас нет таблиц в базе данных с именами Enum в них, значения просто хранятся в крошечных столбцах int.

Я надеялся на что-то вроде предварительного процессора SQL, который "расширил" все перечисления там "волшебное значение".

Ответы

Ответ 1

Вы всегда можете передать значение из перечисления в хранимую процедуру proc/command, которую вы пытаетесь выполнить. Таким образом, вам никогда не придется беспокоиться о перечислениях в базе данных.

Если вы хотите сохранить перечисления в базе данных, я предлагаю вам создать представление (возможно, названное с вашим перечислением), например:

create view JobStatus
    select 0 as Ready, 1 as Running, 2 as Cancelling

Затем вы можете получить доступ к соединению или присоединиться к нему, если вам это нужно.

Примечание. Оптимизатор запросов рассматривает любую ссылку на вышеописанную как постоянную операцию сканирования/скаляра, а не сканирование таблицы, поэтому вы не подвергаете чтению, если бы вы обращались к фактической таблице.

Ответ 2

В одном проекте мы определили атрибут, применяемый к каждому элементу перечисления, который хранит таблицу и значение, ожидаемое в базе данных, и модульные тесты подтвердили ссылку. Мессиально, хотя.

Ответ 3

В чистом TSQL единственное, что я могу думать, это скалярный UDF, который возвращает желаемую область.

В LINQ to SQL вы можете отображать элементы как С#/.NET перечисления, и он обрабатывает их для вас.

Но если честно; в большинстве чистых TSQL я бы в основном использовал только литералы.

Ответ 4

Возможно, вы могли бы реализовать управляемый код на SQL-сервере вместо обычного TSQL? Не 100% уверены, что это сработает, но это может быть вариант для изучения.

Возможное решение здесь...