AX 2012 Наследование таблиц. Краткое описание механизма

[sukhanchik]

Цитата:

Сообщение от fed

Очень, очень забавно. Версия 2012 выпускалась под флагом борьбы за нормализацию структур данных. В итоге - после столкновения с реальностью, в версии 2012R2 пришлось денормализовать те же данные до абсурдного состояния. Скрестить companyInfo и DirPartyTable - это уже денормализация за гранью добра и зла...

Тут важно не столько "скрещивание" DirPartyTable и CompanyInfo - это в целом - не самое страшное скрещивание. По большому счету - юр лица - это те же контрагенты и к ним применима та же функциональность (в частности, ГАК), что и для клиентов / поставщиков. Правда в CompanyInfo лежало еще ряд полей, которым ну явно нечего делать в DirPartyTable, но я думаю - что это не последнее изменение структуры данных таблиц и постепенно все "растащат" по своим местам.

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

Но в целом - я рад, что эта идея не прижилась. Уж больно (на мой взгляд) она была искусственной.

[fed]

Цитата:

Сообщение от sukhanchik

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

Скорее - реализация была безумной. Разумный подход - это когда использование датасорца некоторого уровня иерархии размещает в запросе все датасорцы более высших уровней иерархии, соединенных обычным inner join. Идея, что помещение на форму родительской таблицы также помещает все дочерние с мега-аутер-джойном между ними - что-то из области фантастики. Остается только гадать что употребляли дизайнеры этой фичи - опиаты или каннабиойды...
Ну и конечно, при проектировании прикладной структуры, разработчики должны понимать что каждый дополнительный уровень иерархии таблиц обходится намного дороже чем дополнительный уровень иерархии при проектировании классов. Заводить еще один уровень иерархии из за 1-2-3 аттрибутов - слишком накладно.

[mazzy]

Цитата:

Сообщение от fed

...размещает в запросе все датасорцы более высших уровней иерархии, соединенных обычным inner join...

не забывай, что сейчас кроме самой аксапты в одной связке работают: кубы, отчеты, портал, интеграция с офисом и Project Server'ом. А кроме того, есть куча сторонних приложений (например, тот же Retail), которые "общаются с базой аксапты или с самой аксаптой".

Цитата:

Сообщение от fed

Остается только гадать что употребляли дизайнеры этой фичи - опиаты или каннабиойды...

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