ViPRosavec,

тут умные товарищи наставивали что "не должна", типа никто ниче никому не должен если это явно не затребовано
не написал что интерфейс пользователя должен быть на русском, то могу спокойно на азербайджанском и все будет ок

ViPRos, перегибаете. В ТЗ всегда есть некие границы контекста (как и в любом договоре).
Если в ТЗ указана область применения ПО, разработчик может сам сделать выводы, какой нужен язык. А может сделать и ещё вписать в ТЗ. А может и не сделать никаких выводов - и реализовать на айзербайджанском. И тут действительно всё зависит от степени квалификации и сложившихся отношений обеих сторон.

ТС завёл две темы, но поддержу и здесь:

avec...
Функционал разработан по согласованному с бизнесом ТЗ.
...
По прошествии нескольких лет пришла мысль анализировать то что хранится в этих таблицах.
...


Посмотрите ещё раз:
Несколько лет назад были сформулированы требования.
Несколько лет система работала.
Сегодня вам в голову пришла мысль.
Кто несколько лет назад должен был отвечать за то, чтобы система смогла поддержать вашу сегодняшнюю мысль?
Те кто должен был отвечать - подписали ТЗ (с обеих сторон). У них же проблем нет? :)

avec...
У меня волосы шевелятся от такого подхода, но не могу найти что возразить...
...
Должна ли база быть в согласованном состоянии, с нормально прописанными хотя бы элементарными констрейнтами, внешними ключами, даже несмотря на то что в ТЗ такого ПРЯМОГО требования нет?
База никому ничего не должна.
Спроектирована она в меру понимания заказчика и квалификации разработчика.
И даже работает! (самый главный показатель )
Может быть, разработчики даже задавали вопрос - что делать с удалёнными документами? Сохранившаяся история редактирования без самого документа - просто мусор, который для реализации вашей мысли при анализе вы можете спокойно игнорировать.
Вам это не нравится? Выбиваете финансирование, пишете новое ТЗ, получаете новую систему для реализации "пришедших мыслей" и не бередящую ваше чувство прекрасного.

Извините, опечатался. Конечно же, правильно: азербайджанском .

Petro123R7Вот на это следует обратить внимание. Если мусор от удаленных объектов влияет на БП, отчеты, аналитику, итд, найдите это влияние. И тыкайте им в морду.
+1
+2. Жалко только, ничего существенного ТС не найдёт.

avecНо, например, имеются изменения по документу, а самого документа в системе нет (удален).

Отлично! Есть "журнал", по которому можно увидеть, что документ таки был!

avecЗавожу баг на эту систему.

Можете привести цитату, как сформулирован баг?

avecДолжна ли база быть в согласованном состоянии

В чём её "несогласованность"? Может, пробелма в том, что у вас своё понимание этой самой "согласованности"?!

avecАнатоЛойпропущено...

В чём её "несогласованность"? Может, пробелма в том, что у вас своё понимание этой самой "согласованности"?!

У меня понимание такое http://ru.wikipedia.org/wiki/Ссылочная_целостность .
1. В ТЗ было написано, что база данных этой системы (не СУБД, а именно БД!) должна быть реляционной?
2. Почему вы считаете, что отсутствие ссылочной целостности является "ошибкой" в вашей системе и должно быть исправлено? Потому что так написано в Википедии?
3. Я приводил пример с историей изменения документов и удалённым документом. Как быть в ситуации "удаление документа", если есть внешний ключ из истории изменений на сам документ?
а) удалять историю изменения,
б) не удалять документ, а помечать как удалённый (и тщательно учитівать этот факт во всей бизнес-логике);
в) прописывать в истории "левый ид", делать ещё какие-то пометки и телодвижения, чтобы констрейнт не ругался, и таки удалять строку с документом,
г) ваш вариант....

И, самое главное, для чего всё это: удовлетворить ваше чувство прекрасного за счёт денег бизнеса и потраченного времени разработчиков ?

ViPRosАнатоЛой,

а) удалять историю изменения, - Дать возможность
б) не удалять документ, а помечать как удалённый (и тщательно учитівать этот факт во всей бизнес-логике); - Дать возможность
в) прописывать в истории "левый ид", делать ещё какие-то пометки и телодвижения, чтобы констрейнт не ругался, и таки удалять строку с документом, - Дать возможность
г) ваш вариант.... - Дать возможность
Вместо 1 чел./дня - имеем 5 чел./дней.
Кто заплатит за 4 чел./дня?

avecАнатоЛойпропущено...

Вместо 1 чел./дня - имеем 5 чел./дней.
Кто заплатит за 4 чел./дня?

не согласен с такой оценкой. Статус "удален/не удален" ввести - это одно дополнительное поле + корректные услови я в логике. Если этому принципу подчиняется вся разработка , то условия "WHERE RecordStatus <> 'D'" пишутся разработчиками на автомате
Констрейнты в DDL описать - тоже не ахти какая сложность.
Нет тут "значительного" увеличения трудоемкости.

Ну да, конечно. Сколько нужно тестерам проверить на предмет того, что во всех выборках теперь не всплывают удалённые документы)?!
И это вы только один из 4-ёх вариантов расписали.

avec А уважения к создателям прибавляет Кто против? У всех всегда получается убедить заказчика, что задача/проект займёт не 1 чел./день, а 2? А если счёт не на дни, а на месяцы?
У ТС речь идёт про конкретный случай, и не стоит через несколько лет доказывать, что те вчерашние были неправы, поэтому давайте-ка, сегодняшние, на ровном месте делайте бесплатно работу...

avecP.S. Конечно, базу данных можно использовать, храня в ней одну таблицу с одним полем и все значения писать туда с разделителем "точка с запятой". А че, работать же будет...
Жарким летом кондёр в машине тоже уважения таксисту добавляет, только почему-то не все за кондёр готовы доплачивать.

ViPRosАнатоЛойпропущено...

Вместо 1 чел./дня - имеем 5 чел./дней.
Кто заплатит за 4 чел./дня?
Заказчик, если ему обяснить зачем эти 4 дня
но, если вы НЕ хотите заработать, то можете воще ничего не делать :)
Я не про концепцию в целом, я про конкретный случай, в котором уже имеем свершившийся факт на входе :).