А как Вы думаете, если пользователь знает, что он что-то делает неправильно, он точно не будет так делать? Smile
Если не дурак ( не дура ) - не будет ( нашим узбечкам один раз сказать достаточно, для них позор выглядеть дурами и глазками хлопать ). Никто не говорит, что нужно позволить "запарывать" БД. Но ошибки ссылочной целостности - это логические ошибки, которые на совести пользователя. Потому что только пользователю известно, что некие сотрудники работают в неком отделе и поэтому не нужно этот отдел удалять. Поэтому если он пытается это делать - нужно ему об этом напоминать - он знает, о чем идет речь. Для этого нужно отлавливать такие попытки и выбрасывать сообщения. Как вы отлавливать собираетесь ? Помолившись, без проверок, позволять тразакцию и при ошибках целостности откатываться по ошибке, с последующим анализом ? Как вы представляет обрануружение типа и места ошибки и анализ ? Лично у меня не настолько крепкие нервы, чтобы при каждом апгрэйде сервера надеяться, что коды и реакция на ошибки не изменились.
К чему это все ? Да к тому, что если проверять на целостность самостятельно (100% надежно, тем более, что обычно на руках есть все данные для проверки без перезапроса к БД ), а не полагясь на сервер БД ( фиг его знает, чего там накодировали ) - то зачем эти FOREIGN_KEY, если они только мешают "отрезать" старые записи, а то и намного хуже - вытащить данные при крэше файловой системы, если бэкап неакутальный ? Чтобы админ в командной консоли сервера не напортачил ? Тогда покажите мне того экстремального админа, который делает серьезные изменения через SQL-команды без стартовой команды "BEGIN". Ау!
Что за ужасные сервера БД и жуткие компоненты доступа к ним Вы использовали
Нормальные компоненты и нормальные сервера - но даже код ошибки в таких случаях бесполезен, потому что неясно, откуда и из какой транзакции он приходит.
Не могу удержаться от развенчания еще одного мифа - что индексы, как правило, ускоряют выборки, но никогде не замедляют. Еще как замедляют - в десятки раз ! Имел "радость" с этим столкунуться.
Если в индексе есть одинаковые значения, равномерно распыленные по огромной таблице, то такой индекс породит интенсивнейший дисковый ввод-выдод ( будут читаться все страницы файла с таблицей ), с тормозами как следствие.
Поэтому индексы следует создавать :
1) для полей, практически не повторяющихся при разрастании таблиц - ID-поля, и текущие даты.
2) для индексирования сложных функций ( функциональные индексы), тут просто деваться некуда - ждешь создания индекса час-два, зато потом радуешься.
И все !
Мешающие индексы (по повторяющимся значениям,..) можно выключать, "загрязняя" условие, чтобы оптимизатор не пытался применить индекс :
WHERE a+0.0 = b
где "+ 0.0" выключит индекс по полю "а".
Вообще, спасибо за полемику
