2010-10-01 1 views
4

Правила (Transact-SQL) [1] являются многоразовыми, что позволило преодолеть недостаток невоспроизводимости проверочных ограничений.Правила устарели, что вместо этого (TSQL)?

И теперь я прочитал [1], что:

  • «Эта функция будет удалена в будущей версии Microsoft SQL Server Избегайте использования этой функции в новых разработках и запланируйте изменение приложений, которые в настоящее время. использовать эту функцию. Мы рекомендуем использовать проверочные ограничения вместо этого. Проверьте, создаются препятствия с помощью CHECK, ключевое слово CREATE TABLE или ALTER TABLE»

Итак, что же вместо правил и почему они устаревшие?


==== Update:
AlexKuznetsov, являются проверочные ограничения таблицы уровня очень медленно?
Кроме того, ограничения проверки на уровне таблиц с использованием функций медленны по сравнению с ограничениями проверки на уровне столбцов и соответственно. правила как их эквиваленты (поскольку правила только столбцы)?

Другими словами, ограничения и правила проверки на уровне столбцов (неявно только столбцы) равны по производительности?
Затем я вижу только удаление функции повторного использования. Ранее использовались ограничения на использование таблиц без повторного использования.

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

[1]
MS SQL Server 2008 R2 Books On Line. CREATE RULE (Transact-SQL)
http://msdn.microsoft.com/en-us/library/ms188064.aspx

+3

Вы просто процитировали его сами - вместо правил, '[w] рекомендуем вместо этого использовать контрольные ограничения. Проверить ограничения создаются с помощью ключевого слова CHECK CREATE TABLE или ALTER TABLE' – LittleBobbyTables

ответ

3

Ну одна из причин правила, вероятно, принимая боковой линии, я считаю, с правилами вы можете иметь один на колонке только и они только проверить данные собираются в базу данных, то есть они надевают Проверять существующие данные уже в базе данных. С ограничениями проверки вы можете иметь несколько ограничений для данного столбца, и они обеспечивают соблюдение всех данных (данные поступают и данные уже в базе данных). Учитывая, что правила, похоже, являются бедным решением для того, какие ограничения проверки Microsoft, вероятно, наконец поняли, что настало время избавиться от них, а также не являются стандартом SQL.

Если ограничение проверки не разрезает его, вы также можете использовать триггер для более сложной логики.

3

Если вы беспокойство, вы хотите написать «код», чтобы ограничить раз и повторно использовать его на нескольких столбцах, я предлагаю вам сделать следующее:

Создайте функцию с правилами ограничений:

CREATE FUNCTION schema.PositiveInteger(INT val) 
RETURNS INT AS 
BEGIN 
    IF (val > 0) RETURN 1 
    ELSE RETURN 0 
END 

Добавить эту функцию в качестве ограничения в колонке:

ALTER TABLE tbl ADD CONSTRAINT chkMyRules CHECK (schema.PositiveInteger(tbl.IntColumn) = 1); 

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

CREATE FUNCTION ... (INT val, DATETIME date) RETURNS INT AS ...... 
ALTER TABLE tbl ADD CONSTRAINT chkMultipleCols CHECK (func(col1, col2) = 1); 

Наслаждайтесь!

+0

не очень хорошая часть об этом - медлительность: этот подход ужасно медленный –

+0

Спасибо за ввод. Вы можете его исправить? Также есть ли у вас какие-либо представления о том, что сравнивает эффективность правил с этим? Я знаю, что есть побочные эффекты для проверки ограничений (http://tinyurl.com/2bc2xoe) (и я заметил, что вы видели эту страницу раньше), но я должен представить, что эти побочные эффекты присутствуют в Правилах. Как замена правил, я думаю, что это будет работать довольно хорошо. –

+0

Джефф, я поддержал ваш ответ как полезный, но он несколько ортогонален моему вопросу в контексте введения «современных» (новых) изменений, политики, тенденций. –

 Смежные вопросы

  • Нет связанных вопросов^_^