Здравствуйте, Shamann, Вы писали:


S>а перенос изменений из схемы БД в структуру классов не предусматривается (осмотрел очень бегло, так что, возможно, неправ).
Нет, не предусматривается. 100% есть такие тулзы, но я не интересовался. Насколько я понимаю, это нужно на начальных этапах когда мы пишем приложение читающее из уже существующей базы. Миграции здесь не нужны.

S>Информация, необходимая для принятия решений о той или иной стратегии трансформации, как Вы верно сказали, будет иметь вид метаданных. Однако, при грамотном подходе и реализации механизма принятия решений это позволит более-менее сносно трансформировать модели различными способами и не приведет к созданию большого количества метаданных.
S>По крайней мере можно использовать показатели, характеризующие использование тех или иных структур данных (насколько часто данные извлекаются, модифицируются и т.п.) — я думаю, этого будет вполне достаточно.
Show me the code. Пока это выглядит как "бла-бла-бла мы новый мир построим". Дьявол в деталях.

S>Что касается вопроса об изменениях в структуре классов, то, разумеется, если использовать текстовое представление модели, то будет сложно понять, что же произошло. Использование визуального редактора, по крайней мере, поможет различить операции переименования и создания/удаления.
Стоп, вот у нас есть 2 сущности: модель в коде и схема данных в БД. Чтобы их синхронизировать вы предлагаете добавить третью (данные для визуального редактора)?


S>Кроме того, этот вопрос важен лишь для данных в БД, но не для самой схемы БД.
Если рассматривать схему в отрыве от данных, то лучший вариант: drop/create -- никаких неоднозначностей.


СУВ,