Самое главное в случае каскадного удаления - чтобы дочерние записи не являлись родетельскими для каких-то других записей, и т.д. по цепочке. Сам недавно нарвался на такую ситуацию - удалил одну запись в таблице, в результате волна каскадного удаления прошла по ~20 таблицам, удалилось ~1000 записей. После этого все foreign keys перевел с опции on delete cascade на on delete no action.

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

StrassebahnНу вы блин даёте .....

Пусть решает пользователь - выдать диалоговое окно с вышеукакаными вариантами:
Dim@styУдалять все записи каскадно. (что мне кажеться не очень хорошо)
Не разрешать удалять запись, пока существуют дочерние. (при больших объемах по моему не совсем удобно пользователю)
Показать пользователю все дочерние записи, и с повторным подтверждением удалить все каскадно.


"Ну вы блин даете". Тетенька из отдела кадров при увольнении сотрудника, например, удаляет запись, я ей вываливаю все дочерние из 15 таблиц общим количеством штук 500-1000 (кстати, что подразумевалось под "показать все дочерние записи"? все поля записей? какое-то одно поле? какое? а в общем случае оно может вообще не иметь содержательной для энд-юзера информации). Далее. Как будем удалять дочерние записи? Отказываемся от ключей, и удаляем в транзакции из кода? Тогда информацию о всех связях придется держать где-то в коде проекта, а не в БД, и самому контролировать целостность данных. Или от ключей не отказываемся? Тогда бежать по всем таблицам, и пересоздавать ключи с нужной опцией? Ну, и не говоря о том, что решение относительно дочерних записей может лежать вообще вне рамок компетенции пользователя. Как выше уже правильно писали, такие вопросы должны быть раз и навсегда определены при проектировании системы в целом, и БД в частности (и оговорены в ТЗ на систему).