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

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

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

В общем, как ни крути, а каменный цветок гармонично и живописно из философского камня не выкладывается. Просто не следует забывать, что принципы ООП разрабатывались изначально только в отношении программного кода , и они не могут покрыть всех задач и проблем, когда встает задача обеспечения исторической преемственности хранимых исторических данных , в особенности, когда речь идет о объемных данных, накопленных за существенный период времени.

Какие-то частные решения - да, могут иметь право на жизнь. Но каждое такое решение имеет свои ограничения, хотя для данного конкретного случая, может быть, и наиболее оптимальное. Конкретно про iscra не могу сказать ничего определенного, не считаю себя компетентным в этом вопросе. Тем не менее, полагаю, что, ежели быть откровенным, то вне зависимости от приверженности к тем или иным системам, можно явно озвучить ограничения, описав их характер. И сравнивать именно ограничения одних систем с ограничениями других. Но, при этом, называя их явно и сравнивая именно соизмеримые вещи. Попытки же представить некие системы как системы с отсутствием ограничений (это я не в какой-то конкретный адрес, а вообще), выглядят, ПМСМ, "не комильфо". В любом случае понятно, что либо собеседник не искренен, либо что на глазах собеседника имеются розовые очки, искажающие его восприятие, даже если он и искренен.

Ребята, давайте жить дружно. И давайте изначально не будем исходить из наличия некого злого умысла у своих собеседников. "А ты ему улыбнись" (Крошка Енот (с)). Полагаю, что с момента, когда собеседники перестанут навешивать друг на друга ярлыки, обсуждение может стать гораздо более продуктивным и полезным для всех. Тем более, что тема действительно интересная.