Значения по умолчанию для параметров Always Encrypted

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

CREATE PROCEDURE CreateUser
    (@Username NVARCHAR(50)
    ,@PaymentMethod NVARCHAR(50))
AS 
BEGIN
    INSERT INTO Users
    (   Username
    ,   PaymentMethod
    )
    VALUES
    (   @Username
    ,   ISNULL(@PaymentMethod,'Credit Card')
    )
END

Это чрезмерное упрощение, мы фактически передаем несколько параметров, и некоторые из них зашифрованы, а некоторые нет.

Этот код падает, потому что «Кредитная карта» не зашифрована и поэтому не может быть вставлена в зашифрованное поле, и вы не можете зашифровать поле с ограничением по умолчанию. Хотя можно настроить "defaultPaymentMethod" и передать его, это сделает вызов очень беспорядочным.

Есть ли у кого-нибудь более изящное решение, чем переход по умолчанию? Я уверен, что кому-то уже приходилось делать что-то подобное.

Большое спасибо.

Если вы не знаете дату рождения, почему бы тебе просто не оставить это NULL? Почему бы не использовать date (3 байта) вместо datetime (8 байтов), когда время явно не важно? При чем здесь Always On?

— 01.05.2018 16:06

Это всего лишь один пример, я выбрал dob наугад, но с тем же успехом это может быть способ оплаты. т.е. если вы не настроили оплату, это только кредитная карта. Мы также используем ту же технику для обновлений, которые будут иметь формат DOB = ISNULL (@ DOB, DOB). Когда у вас несколько параметров, нет смысла выполнять обновление для каждого отдельно.

— 01.05.2018 16:11

Что касается того, что это имеет отношение к всегда включенному шифрованию, как я уже говорил выше, «этот код падает, потому что '1900-01-01' не зашифрован и как таковой не может быть вставлен в зашифрованное поле».

— 01.05.2018 16:13

Хорошо, значит, вы имеете в виду «Всегда с шифрованием», а не «Всегда с шифрованием».

— 01.05.2018 16:14

Для сравнения DATE и DATETIME я набрал быстрый пример, демонстрирующий проблему. Я не публикую в Интернете точные данные о компании. Но спасибо за предложение, уверен, кто-то сочтет его актуальным.

— 01.05.2018 16:15

Да, всегда в зашифрованном виде. Как и в заголовке и в теге, введите основное тело, которое я сейчас отредактирую.

— 01.05.2018 16:19

Проблема с установкой значения по умолчанию на стороне сервера заключается в следующем: а) теперь он должен иметь доступ к ключу шифрования, что исключает всю суть использования Always Encrypted, или б) должно иметь уже зашифрованное значение по умолчанию, сохраненное на сервере, которое то означает, что вы можете определить, к каким строкам применено зашифрованное значение по умолчанию, без дешифрования.

— 01.05.2018 16:26

@Damien_The_Unbeliever Я понимаю проблему и причины, по которым данные в базе данных не используются по умолчанию, однако это устаревшая система, которую я унаследовал. В этом случае, даже если я передал способ оплаты извне, я бы увидел несколько экземпляров одних и тех же зашифрованных данных. Тем не менее, мы все еще открыты для предложений.

— 01.05.2018 16:34

На самом деле вы потенциально можете увидеть разные значения для всех строк, если вы используете случайный или детерминированный для этого столбца. Но даже с помощью детерминированного, просто взглянув на таблицу, я не думаю, что вы сможете сказать, какие из них относятся к 1900-01-01, за исключением того факта, что их много (и это зависит от распределения данных и как часто DOB не предоставляется). Во всяком случае, полезна ли эта информация кому-либо, не уверен.

— 01.05.2018 17:07

sql sql-server stored-procedures default-value always-encrypted

01.05.2018 15:57