проверка данных в базе данных: sql против кода

Question

Моя схема базы данных имеет параметр «заблокирован», означающий, что запись не может быть изменена после ее установки.

Перед установкой заблокированного флага мы можем обновить другие атрибуты. Итак:

• Проверяете ли вы заблокированный флаг в коде, а затем обновляете запись

или

• было бы лучше объединить это в запрос SQL, если да, то какие-нибудь примеры?

РЕДАКТИРОВАТЬ: как бы вы объединили обновление и проверку в один оператор SQL?

Answer 1

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

Answer 2

«Как бы вы объединили обновление и проверку в один оператор SQL?»

update table
set ...
where key = ...
and locked ='N';

Это не вызовет ошибки, но обновит 0 строк - то, что вы сможете проверить после обновления.

Что лучше, на мой взгляд, если важен этот заблокированный флаг, то:

• вы должны проверить / применить его в базе данных, чтобы гарантировать, что он никогда не будет нарушен каким-либо методом доступа
• вы можете также проверить / применить его в приложении, если это более удобно для пользователя

Answer 3

Как правило, я бы предпочел проверить все в коде и рассмотреть возможность записи ограничений БД после этого. Когда БД выполняет проверки согласованности для вас, это здорово и, по общему признанию, быстрее, чем делать это в вашем коде, но тогда вы помещаете некоторую логику в БД и должны платить определенную цену. Эти ограничения могут зависеть от поставщика, и, что еще хуже, можете ли вы выполнять автоматические тесты этих ограничений в своей среде разработки?

Так что я бы подумал о том, чтобы помещать подобные проверки в БД в качестве дополнительной сети безопасности, но не полагался бы на них в одиночку.

Answer 4

Я бы использовал триггер, если ваша СУБД предлагает эту функцию для применения флага. Если вы установите флаг, все обновления завершатся ошибкой.

Затем вы можете создать специальный запрос, который обновит флаг. Ваш триггер может проверить то, что называется обновлением, и позволить флагу перевернуться в случае необходимости. Таким образом, будет ли TSQL хорошим или злонамеренным, никто не сможет обновить вашу строку после установки флага.

Answer 5

Я бы проверил флаг блокировки в коде, а затем (при условии, что запись не заблокирована) запустил запрос на обновление, установив флаг блокировки в запросе. Таким образом, его можно заключить в транзакцию и зафиксировать / откатить сразу.