Подскажите, форумяне - есть две переменных одинакового домена с 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 тоже на "поле" вешать или же ты предлагаешь не забыть во всех ХП дополнительно прописать вызов процедуры проверки, а потом отлавливать баги, если где-то забыл прописать?

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

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

Гаджимурадов РустамВообще, термин "дериватив" в этом разделе использовался
только два раза (и оба раза - тобой, и оба раза через "е" ).
И чо?

Гаджимурадов РустамЭх... хоть читать научись, как что сам пишешь, так и то что тебе пишут...
Так что ты там про нерусские слова говорил? Предлагаешь полностью отказаться от использования любых заимствований? Может еще посоветуешь украинцам избавиться в "своей" мове от полонизмов?

Гаджимурадов Рустамrdb_dev> И чо?

Так есть ссылка, где я "употребляю это слово в отношении
подзапросов в соединениях оператора SELECT" или нету?У меня нет никакого желания ползать по всему форуму, выискивая возможное употребление тобой слов "дериват"/"дериватив" в отношении соединений множеств строк из запросов на выборку.

Гаджимурадов Рустамrdb_dev> Предлагаешь полностью отказаться от использования любых заимствований?

Нет, конечно, только от ненужных, тем более из другой области.
В данном случае терминов "дополнительное", "производное",
"служебное", "суррогатное" поле более чем достаточно."Суррогатное"? Ничо не ёкнуло при написании данного слова?

Гаджимурадов РустамОстальное своё бла-бла и политоту засунь куда-нибудь подальше.Где ты политоту разглядел? Про "украинську мову" - чистой воды история! Не веришь мне, посмотри "Букварь южнорусский" Тараса Шевченко от 1861 года. Я же не говорю о том, как из южно-русского говора(молвы) появилась "украинська мова", так как это, действительно, была бы политота. И то не факт...

Мимопроходящий, да, опять! :)

Гаджимурадов Рустам> "Суррогатное"? Ничо не ёкнуло при написании данного слова?

Нет, конечно, давно общепринятый термин в БД.
Равно как и триггер, и куча других заимствований.
То есть, по твоему - "суррогат" и "триггер", это "давно общепринятое заимствование", а "дериват" - совсем новьё? ^^