andrey_anonymousОсновной философский вопрос тут - кто и как контролирует ограничения целостности.В нормальной ситуации дожен вроде как data architect, data modeller или типа того.
Хотя не смотря на наличие множества вакансий типа data modeller в забугорье, это несколько абсурдная должность.
Нельзя моделировать что-то по 8 часов в день целый год и больше.
И главный момент - у модели должен быть один владелец, который подтверждает изменения если их делают творческие личности.
andrey_anonymousВ такой парадигме разработки сидит команда джавистов/сишников/пхпшников (нужное добавить/подчеркнуть), "пидалит код" и по необходимости гуглит sql-запросы.И как известны успешные примеры внедрения и эксплуатации при более-менее серьезных нагрузках?
Мне не попадались ни разу успешные проекты, в которых нет хотя бы одного человека среди разрабов, который cares about data.
andrey_anonymousЕсли в этой команде заводится "констрэйнт-наци", который лепит в БД все-все ограничения в меру собственного понимания - то разработка сначала становится заметно дороже, а в конечно итоге может запросто встать.Про вставшее это на личном опыте или фантазия?
Лепить надо не из собственного понимания а исходя из реалий.
В Оракле есть error logging и при анализе данных из таблицы ошибок либо правятся исходные данные либо меняются constrains.
Я в курсе, что тебе это известно, порсто было сказано к тому, что существующие инструменты сильно упрощают и в итоге ускоряют разработку и улучшают data quality.

В Hadoop нет integrity constrains и должен сказать это полнейший ад.
Разработка идет не в 2 раза медленее по сравнению с Ораклом, а в 5-10 раз медленее и постоянно надо чистить мусор, упрощать и стандартизировать подходы.