Сам, увы, по нормальному с DAX2012 так и не работал, поэтому выскажусь на "общечеловескую" тематику основываясь на предыдущих сообщениях темы.
Чтобы понять что случилось надо рассмотреть возможные варианты отображения иерархий классов в таблицы БД. Применительно к DAX таблица в AOT с полями и методами это "класс", а соответствующая таблица в БД это просто "таблица"
Несомненно наличие механизма отображения иерархий классов в реляционные бд вещь полезная, хоть и не жизненно необходимая
Существуют три общепринятых способа такого отображения
1. Для каждого класса иерархии своя таблица в БД, содержащая только поля данного класса
+ прямолинейное отображение классов в таблицы, нет лишних полей, экономия пространства
- чтобы получить данные конкретного класса нужен join
- при измении структуры классов, перемещении полей надо следом всё это повторять в бд, т.е. физически перемещать поля между таблицами вместе с данными
2. Для каждого конкретного (неабстрактного) класса своя таблица в БД, содержащая все поля как данного класса, так и всех предков
+ Лишнего места (как и первый вариант) не занимает
+ Нет джойнов
- Для построения каких либо отчетов и прочих операциях по промежуточному уровню иерархии появляется union
- Так же как и в случае с первым вариантом изменения структуры классов приводят в необходимости следом изменить структуру таблиц, причем так как поля дублируются во многих таблицах, всё еще гораздо "запущеннее"
- Проблемы с уникальностью ключевых полей. Так как индекс на каждой таблице свой, а constrain-ы привязаны к индексу, весьма вероятны задвоения значений ключевых полей. Т.е. БД перестает даже помогать управлять уникальностью значений и это должно быть реализовано в приложении
3. Для всей иерархии одна таблица в БД, содержащая все поля всех классов иерархии
+ Никаких: join, union, проблем с уникальностью, проблем с поддержкой изменений иерархии
- Не оптимальное расходования места (хотя некоторые бд умеют более умно хранить дефолтные значения столбцов и места пропадает меньше)
Вариант 1 теоретически красив, радует глаз и сердце архитектора и в идеальном объектом мире идеален. Джойны? так СУБД умеет джойнить. Надо тасовать данные при изменении иерархии? А для для чего еще нужны БД, если не для этого. И этот вариант как раз то что появилось в DAX2012. Всё по учебнику, всё красиво и "супер-супер".
Реальный мир, как обычно, практичен и несовершенен. Тучи джойнов напрягают сервера, но не это самое страшное. А вот когда поле передвинули в иерархии и это приводит к необходимости следом переносить столбцы вместе с данными между таблицами, то это уже очень невесело для реальной жизни. Сделать такие изменения "на ходу" даже теоретически непросто и не быстро, не говоря уже о системе 24x7. Дополнительным "увеселителем" ситуации выступают всякие кубы/порталы/репортинг сервисы и прочие примкнувшие приложения, которые мало или вообще ничего не знают о метаданных DAX, а полагаются в основном на ее БД и дружно отказываются работать при изменении ее структуры.
Механизм наследования таблиц сам по себе уж точно не лишнее для DAX. Поэтому решение перейти на 3 вариант, вернув одну широкую таблицу в БД, но оставить все остальное на месте вполне разумный шаг и, по сути, признание своих ошибок. И хотя бы это радует. Учебники, между тем, настоятельно рекомендуют начинать именно с третьего варианта
