Мне сдается в mysql виноват 4 параметр pos, он как бы указывает заменять с первого символа, а строка пустая.
Если мы не подразумеваем получение рутового доступа взломщиком, зачем вообще шифрование?
Если пользователь это машина деплоя, которая накатывает миграции, то нужно
Да, стандартная защита для ключа, это спасет если ключ дискредитирован. Но так как он по прежнему присутствует гдето в БД, то дискредитация СУБД приводит к доступу ко всем данным системы.
Т.е. привилегированный доступ к любой из 2х машин (СУБД или к клиенту) даст доступ ко всем данным, в отличие от системы где шифрование в сервисе клиенте СУБД, там доступ к СУБД ничего не даст.
Я просто не вижу ситуации когда следует предпочесть эту схему вместо схемы с шифрованием вне СУБД.
Пробывал jsonb_to_record но new после нее остается пустым
В текущей схеме, деплой машина (вернее ее роль) не сможет записать такой триггер (вернее ее процедуру), т.е. создание всех таких секретных объектов будет осуществляться суперпользователем вручную? Или нет?
но все это надо ведь както расшифровывать. Значит клиент будет запрашивать расшифровку и передавать ключ? А если клиент знает ключ, значит то, что мы усиленно оберегали выше бессмысленно и ключ все равно будет лежать гдето на 3ей машине. А раз так, то шифрование на клиенте БД выгоднее, т.к. даже дискредитация данных суперпользователя БД не даст доступа к данным, нет проблем с деплоем любых изменений и шифрование будет проходить в приложении, которое скорее всего проще масштабировать.
А DEFAULT UTC_TIMESTAMP не работает.
CREATE TABLE test (
id INT,
dt DATETIME DEFAULT CURRENT_TIMESTAMP,
udt DATETIME DEFAULT (UTC_TIMESTAMP())
);
SET SESSION time_zone = '+00:00';
INSERT INTO test (id) VALUES (1);
SET SESSION time_zone = '+06:00';
INSERT INTO test (id) VALUES (2);
SELECT * FROM test;
id dt udt
1 2025-02-03 08:23:55 2025-02-03 08:23:55
2 2025-02-03 14:23:55 2025-02-03 08:23:55
а неделя же это просто 7 * 24 * 60 * 60 * 1000
если использовать не datetime / timestamp а просто big int, то смещения уже не будет существовать
А когда хранят в базе что-то подобное 2025-01-31t12:55:43, то это какой-то мрак.
Я время, в базе, хранил как метку в секундах, да и до сих пор так делаю. А если надо в человеко-понятный уровень превратить, так в PHP есть date(), и в js new Date()
Нарисуйте схему - все устройства, все их интерфейсы и соединения, настройки каждого устройства и настройки каждого интерфейса (маршрутизация, NAT и т.п.). Так станет понятнее, где и что должно быть.