donkey80P.S.: Конечно, такой подход скорее всего неприменим для многих систем; также, я не могу сказать, что я досконально продумал его. В связи с этим прошу не заострять внимание на технических аспектах, а высказываться по поводу самой идеи.
Ну это собственно идея очереди сообщений. Она имеет вполне очевидные достоинства и ограничения, и потому применяется... более локально. Как архитектура ИС в целом - вряд ли сработает.

Что до названных Вами минусов "традиционного подхода", то:

Первый минус этой идеей никак не решается - данные по-прежнему легко испортить теми же методами

Второй минус решать так.. вряд ли разумно. Если не устраивают скрипты, стоит искать более продвинутые решения - например, конвертацию старых данных в момент следующего обращения к ним.

ViPRosкакого фига какая та часть модели(БД) должна оставаться неизменной?
В силу универсального принципа "мне так проще". Мне проще решить сугубо клиентскую задачу на сервере, нежели учить ещё и программирование клиентов. Мне проще послать клиенского программиста, пришедшего с серверной задачей, решать её на клиенте, чем морочиться самому. Мне проще, получив от серверного программиста хамский отлуп, проглотить и уйти делать на клиенте, нежели найти способ вставить ему пистон под хвост. И так далее.

Озверинслой DAO может неадекватно отреагировать.
Вообще говоря такому слою надо делать формат цэ. Если, конечно, мы говорим о совместимых изменениях. Последние примерно 50 лет - с тех пор как придумали модульное программирование - дизайн приложений в значительной степени определяется поиском loose coupling, и если один компонент падает от незначимых изменений в другом, это говорит о необходимости срочной хирургии передних конечностей. Именно так и появляются массы уродцев, которые вроде как сделаны по науке, но если попробовать внести тривиальное изменение, оказывается, что для этого надо править в десяти местах код на трёх разных языках.

Тем не менее, позволю себе упомянуть, что Валерий наверняка подразумевал и необходимое изменение клиентов в рамках "изменить БД".

ОзверинЕсли ж вам трудно преставить, как в одном изменения в 1м модуле могут повлечь ошибки в другом - мне сказать нечего ;) Мы с вами на разных планетах живем.
Мне это очень легко представить. Как и последующую операцию по выпрямлению рук того, кто это напрограммировал.

mcureenabКороче, некие паттерны проектирования.
Первый и главный паттерн в такой ситуации - "владелец". У каждого значимого фрагмента метаинформации должен быть единственный источник, нужно исключать дублирование.

Скажем, давайте рассмотрим вышеупомянутую проблему редизайна колонки в таблице. Первое, что нам нужно решить - сколькими значимыми (именно значимыми) фрагментами метаниформации должно в данном случае руководствоваться приложение. Допустим, мы решили, что такой фрагмент один. Что это значит на практике: если мы считаем, что этот источник размещён в СУБД, значит, приложение берёт из неё всю метаинформацию по атрибуту. Если считаем, что размещён в приложении - значит, приложение при необходимости модифицирует структуру БД в соответствии со своей метаинформацией. В любом случае приложение генерирует интерфейс, пользуясь для этого метаинформацией по атрибуту. Проблемы "приложение накрылось из-за изменения колонки", само собой, не возникает.

Допустим, мы решили, что фрагментов таки несколько. Например, мы хотим не генерировать интерфейсную форму, а нарисовать её явно, то есть воспользоваться некоей информацией по дизайну, вовсе не заложенной в метаинформацию колонки в БД. Что мы получаем в этом случае? Мы получаем необходимость маппинга, указания некоего соответствия между свойствами/объектами этих фрагментов. Каким должен быть этот маппинг? Ответ: минимально сковывающим и максимально адаптивным. Допустим, у нас на форме есть чекбокс. Допустим, мы завтра решили, что логические поля в оракловой БД должны представляться не как CHAR(1) со значениями Y и N, а как NUMBER(1) со значениями 1 и 0. Вопрос: хотим ли мы бегать по всему приложению и переделывать все чекбоксы? Ответ: нет, мы хотим, чтобы информация была представлена в единственном экземпляре с одним владельцем. Поэтому в каком-нибудь Oracle Designer-е мы опишем для логических данных домен, и не будем при изменении этого решения править руками сто двадцать описаний полей. Поэтому в клиенте мы тем или иным образом укажем, какое значение DAL должен передавать в СУБД как значение true и какое - как значение false. Должно ли в данном случае приложение запрашивать эту информацию у БД? Пожалуй, в данной ситуации будет выгоднее допустить мелкое дублирование, это осознанное решение. Хорошо, теперь, допустим, мы поменяли тип колонки с VARCHAR(100) на VARCHAR(200). Как должно отреагировать на это приложение? Самый простой ответ - никак! У него для этого атрибута String, безразмерный, и приложению вообще пофиг на это изменение. Ладно, допустим, приложение что-то делает с этим значением, например, регулирует ширину колонки в гриде или проверяет на допустимость при заполнении. Как в таком случае должно реагировать приложение? Правильно, прежде всего мы должны решить, у нас один фрагмент метаинформации или два. Если один - должно запросить с сервера и использовать. Если два - должно поддерживать собственную метаинформацию и стараться конвертировать при маппинге там, где это необходимо. Передать в СУБД String(100) и нехай оно превращается в VARCHAR(200). Да, в случае маппинга заведомо закладывается возможность "не удастся конвертировать", но этот случай не вызывает никаких проблем непонимания, поскольку проходит в случае нетривиальных изменений бизнес-логики. Но почему в таком случае приложение падает, когда мы меняем date на timestamp или varchar(100) на varchar(200)? Ответ: потому что придурки программисты (чаще не прикладные, а создатели фреймворков) заложили в реализацию дублирование метаинформации, логически являющейся одним фрагментом. Вместо того, чтобы получать информацию с сервера, вместо того, чтобы уметь конвертировать date в timestamp, они просто и тупо ругаются "несовместимый тип поля". Вот и весь паттерн.

iscrafmмне даже тяжело представить, чтобы именно фреймворки на таком лажались.
Ну, just for example, на таком лажались persistent fields в дельфях, во всяком случае при использовании BDE, хотя по-моему не только. Самое весёлое, что я помню - приложение при той же, нетронутой базе, и при том же, нетронутом exe-шнике, падало от мелкого патча BDE. Причина - NUMBER(*,0) поля в таблицах в этом патче стали рассматриваться не как ftInteger, а как ftFloat (или наоборот, не помню).

iscrafmТ.е. процитированный фрагмент скорее антипаттерн
Ну вот с этим я нисколько не спорю С этим не согласен, кажется, Озверин.