Констрейны нужны.
вот почему.
1. В БД данные могут попасть любым способом, через Сервер Приложений, Федерацию, Через запросы в этой же базе, Импорт из csv фала и т.д. И во всех этих случаях не возможно учесть ограничения на данные, лучше чем констрейны здесь ни кто не справиться.
2. При использовании связи в БД, а не декларативно в коде, всегда понятно что с чем связанно. Легче запросы писать (Есть у вас есть ПК в таблице? вы уже знаете что запрос дубляж не вернет).
3. Ну и они еще на некоторых СУБД помогают при оптимизации.

Ну и на последок представте что БД это тоже своего рода сервер. А Серевера приложений клиенты. Вы же на сервере (т.е. БД) должны проверять то что вам прислал клиент (приложение на сервере приложении, прямое соединение через JDBC и т.д. и т.п.)

explaolzhas,

1. в настоящее время декларативные ограничения целостности поддерживаемые СУБД далеко не всегда позволяют описать все инварианты модели данных. Так что на долю прикладного кода остаётся достаточно работы по проверке данных.

Согласен не все, однако можно задейсвовать хранимые процедуры, UDF. (Я к этому не призываю, это как контр аргумент)

expla
2. для описания БД служит проектная и эксплуатационная документация. Опять таки в силу ограниченности возможностей СУБД вы не сможете описать все свойства данных на только уровне ограничений целостности.


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

expla
3. иногда помогают, иногда мешают. если помогают, то от чего ж их не использовать... речь то о том, что тут они скорее мешают.

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

expla

4. БД в силу своей пасивной природы не может быть сервером. Сервер, это СУБД. А проверять данные нужно лишь в той мере, в какой это необходимо для корректной работы системы. Для БД существенно лишь соответствие данных структуре хранилища и типам полей записей, чтобы СУБД могла корректно извлечь эти данные из файлов БД и предоставить эти данные пользователю. Остальное, это подпорки для логики приложений.
А что вы подразумеваете под словом сервер? Давайте выкиним и связки сервер приложений и построим обычную двух звенку, И что по вашему в этом случае будет сервером?

СУБД расшифровывается как Система Управления Базами Данных, она должна управлять данными, а не быть просто хранилищем.

Да и вообще считаю, что спорить бессмыслено. Все постигается в Практике, вот у меня задача, как раз такая. Такое ощущение, что проектировщик при проектировании вообще не понимал значения ключей. Теперь вот разбираюсь с этим бардаком.
Не спорю можно и в Сервере приложении все так разработать, что будут работать как часики, а БД использовать просто что бы быстро достать данные. Но я же все таки склоняюсь к возможностям БД, на мой взгляд это правильнее.

Goffman,

Вы мене напомнили один случай, у нас тоже заливка из других систем при чем миллионами записей. Начали заливать, опа ключ мешает. Что делать?! Снесли ключ залили данные. Все задачу выполнили.
А потом через пол годика выходит а от куда тут эти данные, а почему данные по 2 раза залились и т.д. и т.п.

На счет противоречий контстрейнов, с начало нужно констрейны в порядок привести, а потом уж и данные перегонять.
Вы когда поле в таблице из null -> not null переводите вам база что говорит (при условии что есть нулевые записи)?

egorychлучше гемор, чем превращение БД в хранилище мусора.
+1