Как я должен работать в этом сценарии. Должен ли я использовать Trigger или Leave on User для управления

Question

Я создаю приложение, в котором я использую хранимую процедуру, в которой я реализую свою логику.

Теперь мне нужно знать, что я хочу, чтобы моя база данных не содержала недопустимых записей, для этого я должен создать триггеры для реализации моей логики проверки данных , такой, чтобы при изменении FailPasswordAttemptCount на какое-то значение тогда я должен внести изменения в соответствующий столбец IsLocked соответственно через триггеры или оставить его на dba для управления.

например

if FailPassowrdAttemptCount > 3
  IsCaptchaActivated=True
if FailPasswordAttemptCount>6
  IsLocked=true

теперь, если dba изменяет значение FailPasswordAttemptCount на 4 без изменения IsCaptchaActivation на true, тогда это сделает недопустимую запись для моего веб-интерфейса. Так что я должен управлять этим через триггеры или я должен оставить его через dba, чтобы сделать правильный ввод.

Хотя этот тип записи невозможен через внешний интерфейс, но в случае, если any1 имеет привилегии для доступа к базе данных, изменения напрямую выполняются через базу данных. Для этого я должен оставить это на пользователя или я должен управлять через триггеры. Я хочу, чтобы моя база данных оставалась последовательной при любых обстоятельствах.

Answer 1

Я бы сделал следующее:

• Поместите логику проверки данных в хранимую процедуру
• Сделал хранимую процедуру единственным способом взаимодействия приложения с таблицей
• Поместите нужный код в хранимую процедуру.

Парадигма программирования, основанного на триггерах, становится слишком трудной для кодирования и сопровождения по мере увеличения сложности бизнес-логики вашего приложения.

Однако, если вы абсолютно уверены, что у вас будет только простая логика, подобная этой, все в порядке, чтобы включить ее в триггер, поскольку это потребует минимальных изменений в способах взаимодействия приложения с базой данных.

Answer 2

Я бы не использовал триггер для чего-то подобного. Триггеры неясны и их сложно отладить для разработчика. Используйте ваши таблицы и хранимые процедуры для решения этой проблемы. Используйте триггеры, когда у вас нет альтернативы.

Answer 3

Я бы использовал комбинацию обоих. Я постараюсь максимально ограничить данные. И сработает триггер, чтобы никто не мог вставить недопустимую запись.

Answer 4

Я бы реализовал это в логике приложения. При вызове входа в систему sproc вы можете указать как успешное выполнение, так и количество неудачных попыток ввода пароля, а также необходимость использования капчи. Независимо от того, если администратор базы данных изменит 3 на 4, ваш код увидит 4, проигнорирует результат проверки и предоставит пользователю капчу. Если вы беспокоитесь о том, что администратор БД изменяет код напрямую, вы также можете проверить функцию / переменную APP_NAME (), чтобы узнать, какая программа пытается изменить данные. С этим нужно быть очень осторожным, но администраторы баз данных модифицируют поля напрямую.

Answer 5

Для ситуаций такого типа я бы, вероятно, не использовал триггер, только для ситуации, которую вы описываете. Хотя мне было бы интересно, почему у вас dba вручную изменяет данные в поле, которое тесно связано с безопасностью вашего приложения.