Предварительная или пост проверка при удалении записей из таблицы

Для веб-приложения, где удаление записей происходит часто, что является лучшим, если принять во внимание эффективность?Предварительная или пост проверка при удалении записей из таблицы

проверить, имеет ли запись какое-либо переименование с другими таблицами и не позволяет пользователю удалять.

например: запрос будет как этот
```
if not exist(select * from table1 where tableX_id = @id) and 
     not exist(select * from table2 where tableX_id = @id) 
     ... 
    then 
     delete from tableX where id = @id 
```
или
выполнить delete и пусть СУБД RAIS ошибку из-за foriegn key ограничения
```
try{ 
     Service.DeleteRecord(id) 
    }catch{ 
     Handle the error here 
    } 
```
в этом случае запрос будет простой
```
delete from TableX where id = @id 
```

источник

2012-06-08 anouar.bagari

Почему вы не можете использовать каскадное удаление в связанных таблицах? – Arion

@Arion Я не хочу удалять записи, упомянутые в других таблицах –

Почему вы этого не хотите? Я имею в виду, что вам не нужно ничего проверять при удалении. Вам не нужно ломать никаких ошибок. Вы можете просто оставить sql-server сделать это «job» – Arion

Если цель состоит в том, чтобы исключить удаление строк только в том случае, если фактическое выполнение удаления приведет к ошибке, поскольку оно ссылается на другие таблицы, то я предлагаю вам проверить наличие нарушения, прежде чем позволить SQL Server проверить вас , I've done some testing on this and letting SQL catch the error or just using TRY/CATCH can be more expensive if you expect even a moderate amount of failures. При наличии надлежащих индексов дополнительная стоимость выполнения проверки незначительна; однако стоимость НЕ совершения проверки, конечно, МЕНЬШЕ незначительна.

источник

2012-06-08 14:20:37

Проверить, что для устранения гонок для удаления требуется подходящая транзакция (и соответствующая изоляция и блокировка), в противном случае вам придется иметь дело с возможностями ошибок, исходящих от Delete в любом случае. –

То, что «с соответствующими индексами на месте» в вашем ответе имеет все значения и может очень контрпродуктивно в других сценариях или просто невозможно сделать по другим деловым причинам. – Icarus

@Damien_The_Unbeliever да, я не говорю, что это замена, вы, вероятно, все же захотите попробовать/поймать или другую обработку ошибок на месте, но если во время проверки, если строка не прошла проверку, нет смысла вводить удаление фазе на всякий случай, если какая-то другая транзакция сделала возможным удаление. Тем не менее использование try/catch (или просто выполнение удаления при успешной проверке проверки) все равно поймает край, где между проверкой и удалением удаление стало недействительным. –

Очевидно, что выполнение и удаление РСУБД позаботились о бизнесе. Осуществляя проверку самостоятельно, вы выполняете дополнительную операцию, которую RDBMS будет выполнять в любом случае.

источник

2012-06-08 14:09:38 Icarus

Я бы использовал триггеры базы данных (или ON CASCADE DELETE) для обработки любых отношений - доступные инструменты будут зависеть от вашей РСУБД.

источник

2012-06-08 14:11:13

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

Поскольку вы специально задавали вопрос о проверке отношений с другими таблицами, как вы планируете обрабатывать осиротевшие связанные записи? –

Я думаю, что в этом смысл - если он удалит строку в X, где ни одна строка в Y не указывает на нее, она не оставит сирот. –

Предварительная или пост проверка при удалении записей из таблицы

ответ

Смежные вопросы