Это произойдёт в случае, когда целостность данных проверяется клиентским кодом. Ограничения же в структуре данных в принципе не позволят сохранить данные, нарушающие эти условия-ограничения.
Вот об этом и речь. Ошибка в том, что Вы низводите сервер до уровня тупого хранилища. И не желаете признавать что та часть кода, которая располагается на SQL-сервере, является равноправной частью приложения.
Вы сегодня пишете код на питоне, завтра захотите перейти на шарп, потом на джаву... в чём разница с утверждением про изменение SQL-сервера?
Ну произошла ошибка... и что? Уйдёт багрепорт, код допишется и будет нормально проверять входные данные. До следующего багрепорта. Обычная ситуация.
??? Связывание на основании первичного ключа как существующий объект - фикция.
Есть установление значения в зависимой записи поля, определяющего связь, в значение, взятое из зависящей записи - собственно то, что мы считаем процессом связывания.
PS. Всё обсуждение - имхо последствие попытки низвести SQL-сервер до роли тупого хранилища данных. И выполнять абсолютно всю обработку на клиенте. Тебе дали - храни. С тебя спросят - отдашь.
с чего был сделан столь вопиюще странный вывод, что запись не будет сохранена в БД
UUID генерируется и сохраняется в БД, но не попадает на клиентскую сторону, ибо там он нахрен не нужен.
Не в курсе жив ли еще пайониир, но думаю сейчас виртуальных карт немало.
Кроме того, как и любой бизнес, апворк чхать хотел где вы находитесь физически, никто не станет терять деньги из-за того что вы как-то относитесь к России, если вы заходите в аккаунт не из российского пула адресов.
