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

WildSery, вообще-то, я ожидал ответ... :)

WildSery, я правильно тебя понял - CHECK будет отрабатывать всегда, чтобы не зависеть от версии метаданных?

Всем спасибо!
Так как мне достаточно только одной проверки, нужно было понять - стоит ли дополнительно вводить дереватив домена без CHECK.

В моем, конкретном, случае, никаких внешних условий нет, а есть составной идентификатор BIGINT, вычисляемый по определенному правилу. В CHECK прописана процедура, проверяющая соответствие условиям формирования идентификатора, но одно дело - сформировать идентификатор разово, при создании записи оператором, а другое - нагружать сервер проверкой идентификаторов данного домена на поле с внешним ключом, при высокой интенсивности вставки записей в таблицу.

AriochКстати да, достаточно в CHECK-условие ввести нечистую функцию, некий чёрный ящик, обращающийся ко внешнему контексту (например дате-времени, или курсу валюты), и одно и то же значения может в разное время проходить проверку и проваливать.

ЗАЧЕМ такое делать - вопрос отдельный, и не серверу его решать.В MySQL, к примеру, для хранимых процедур/функций есть опция DETERMINISTIC, позволяющая разработчику указать серверу, что в любой момент времени и для одних и тех же параметров, значение функции принимает одни и те же значения.

Гаджимурадов Рустам, может, всё таки, для внешнего ключа проще создать домен-дереватив без CHECK, при том, что в зависимую таблицу данные валят интенсивно и не переставая?

Гаджимурадов Рустамrdb_dev> может, всё таки, для внешнего ключа проще создать домен-дереватив без CHECK
rdb_dev> при том, что в зависимую таблицу данные валят интенсивно и не переставая?

Во-первых, если ты думаешь, что использование умных буржуйских слов
(особенно, когда есть более привычные термины, в т.ч. на русском языке)
добавит тебе весомости, сделает твою речь понятнее, а жизнь приятнее -
ты ошибаешься. Отнюдь, весьма, не только лишь всегда. (с)То есть, когда ты употребляешь это слово в отношении подзапросов в соединениях оператора SELECT, то это нормально, а когда я употребляю это слово в более широком его смысле, то я выпендриваюсь? Сказочно...

Гаджимурадов РустамВо-вторых, CHECK никаким боком не относится (в т.ч. не проверяется)
к внешим ключам (я говорю о поле, на которое ссылаются FK, а не сами
FK-поля дочерних таблиц, конечно). Если же ты собрался на FK-поле
дочерней таблицы CHECK повесить, то технически это можно, конечно,
но практически трудно обосновать этот вывих логики.Трудно обосновать использование одного и того же домена для полей первичного и вторичного ключей? Сам-то понял, что сказал?

Гаджимурадов Рустамrdb_dev> То есть, когда ты употребляешь это слово в отношении подзапросов
rdb_dev> в соединениях оператора SELECT, то это нормально

Ась? Я использовал слово "дереватив" (через "и" правильо пишется, кстати)Да, через "и", но, как я вижу, ты понял о чем идет речь.

Гаджимурадов Рустам"в отношении подзапросов оператора SELECT"? Шариков, Вы никак рехнулись?Кто же тебя, чудака, модератором назначил?
За твои "способности" к общению и переход на личности тебя надо банить навечно.

Гаджимурадов Рустам> Трудно обосновать использование одного и того же домена для полей
> первичного и вторичного ключей? Сам-то понял, что сказал?

Конечно, понял. Домен-домену - рознь, как я уже сказал выше - вешай CHECK
не на домен, а на поле. Чисто теоретически, можешь ещё в трекере type of column
для таблиц попросить, но я сомневаюсь, что эта фича будет иметь высокий
приоритет у Кальтенбруннера (а у остальных - и подавно).
В хранимых процедурах мне CHECK тоже на "поле" вешать или же ты предлагаешь не забыть во всех ХП дополнительно прописать вызов процедуры проверки, а потом отлавливать баги, если где-то забыл прописать?

Узбагойзя! Я получил ответ на свой вопрос и все твои потуги - лирика.

Гаджимурадов РустамСсылку в студию! :) Не проблема...