> Согласитесь, что и вы и я пока не видят недостатков наших решений.

То, что Вы описали - не решение. Решение - это собственный справочник + описание внешних источников + политика работы с внешними источниками. Других решений нет.

> Сформулируем на уровне таблиц наши решения

Формулируйте. Мне эта задача неинтересна.

Hint: только для того, чтобы построить метаописание объектов Вашей базы данных, которое я бы использовал в числе прочего для описания политик, мне потребуется порядка сотни (чуть меньше) таблиц. Ну и на кой хер оно мне надо? Чтобы Вас в чем-то убедить? Эффект не адекватен затратам.

> спросим у банковских автоматизаторов. на их форуме.

А что, банковские автоматизаторы - по определению грамотные проектировщики? Кто Вам это сказал?

> Блин, а я то два года маюсь над примитивными банковскими системами.

Ну и?

> Это по-вашему они детерминированные, а по-реальному - нет.

Это не по-моему они детерминированные, а по определению банковских систем.

> Огласите критерии "непримитивности задачи".

Не готов. Но точно - не детерминированные системы.

> если не интерестно, то зачем вы тогда сюда пишете.

Если мне неинтересна конкретная задача, это не значит, что я вообще не могу писать, правда? Этот тред читаете не только Вы.

> Лично я интерпретирую вашу позицию, как лицемерную. Пишете одно, а делаете
> другое.

Это исключительно Ваши проблемы.

Возвращаясь к предмету обсуждения, подчеркну еще раз: для примера описания политик мне потребуется привести структуру для метаописания объектов базы данных. Не буду этого делать по двум причинам. Во-первых, сильно сомневаюсь, что Вы вообще понимаете, о чем речь, во-вторых, это слишком объемная задача для того, чтобы просто привести ее в качестве примера.

Ответ на Ваш вопрос относительно поведения системы при отсутствии данных в [1460596] дан исчерпывающий. Читайте внимательнее.

> А где по вашему критерий грамотности.

Ну вот Вы можете найти в тексте грамматические ошибки? Точно так же можно найти ошибки в структуре данных.

Г-н softwarer imho абсолютно справедливо предложил в качестве формального метода оценки совокупную стоимость владения. Только считать ее - это отдельная нетривиальная задача. ;)

> Мой критерий - это практическое подтверждение.

Это не критерий.

> Одно дело говорить, другое дело когда на системе реально работают.

Ну и? Кто сказал, что программулина с криво спроектированной структурой данных не должна работать?

> Банковские автоматизаторы точно знают как это сделано в системе, которая
> используется у них.

Ну и что, что они знают? Дружище, Вы полагаете, что структура данных банковских приложений - заведомо эталон проектирования? Кто Вам сказал такую глупость?

> Как вы подтвердите свой высокий уровень?

Никак. А почему Вы считаете, что я вообще должен это делать? Предложено решение; хотите - делайте, не хотите - не делайте. Корысти - никакой.

> Ибо надо предполагать, КАКИЕ ИМЕННО изменения могут быть,

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