D365, SysDatabaseLog, поле NewData

[Raven Melancholic]

И опять иерархия наследования таблиц, грустно.
Я считал, что те проблемы, которые наследование DAX2012 создало в ранее существующих механизмах, это просто проблемы роста. Но вот уже D365 идет по планете, а воз и ныне там.
Впечатление, что команда предложившая и реализовавшая наследование таблиц, появилась на проекте, что-то сделала и слиняла в другие проекты.

[sukhanchik]

Цитата:

Сообщение от Raven Melancholic

И опять иерархия наследования таблиц, грустно.
Я считал, что те проблемы, которые наследование DAX2012 создало в ранее существующих механизмах, это просто проблемы роста. Но вот уже D365 идет по планете, а воз и ныне там.
Впечатление, что команда предложившая и реализовавшая наследование таблиц, появилась на проекте, что-то сделала и слиняла в другие проекты.

Если посмотреть на это глазами большой компании - то ведь как было:
1. Реализация наследования в AX2012RTM. Когда реально каждая таблица, участвующая в наследовании была реальной таблицей в БД.
2. Реализация наследования в AX2012R2. Когда всю иерархию таблиц слили по структуре данных в одну корневую родительскую таблицу. Т.е. теперь физически с т.з. БД любой запрос к подчиненной таблице в иерархии (в АХ) превращается (в БД) в запрос к корневой родительской таблице с фильтром по полю InstanceRelationType, в котором сидит TableId подчиненной таблицы.

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

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

[twilight]

Цитата:

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

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

Так в первом варианте реализации даже теоретически нельзя индекс такой сделать. Т. е. получается концепция наследования таблиц в целом нежизнеспособна?

[Damn]

Цитата:

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

Т. е. получается концепция наследования таблиц в целом нежизнеспособна?

Почему в целом нежизнеспособна.
Концепция из пункта 1 могла бы нормально жить. Когда в БД каждая таблица - отдельно. Непонятно почему этот вариант отвергли.

[sukhanchik]

Цитата:

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

Т. е. получается концепция наследования таблиц в целом нежизнеспособна?

Лично я считаю, что в той реализации, которая была сделана в АХ - да, нежизнеспособна. Да, такая вещь, как наследование методов может быть и удобна, но она легко (и с бОльшим удобством) может быть вынесена на иерархию классов. В остальном - пользы нет.

Цитата:

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

Почему в целом нежизнеспособна.
Концепция из пункта 1 могла бы нормально жить. Когда в БД каждая таблица - отдельно. Непонятно почему этот вариант отвергли.

Всё верно, в ситуации, когда каждая таблица отдельная - действительно эта концепция более жизненная.... Если не учитывать вопросы производительности. Но вопрос производительности - ключевой. Джойн из нескольких таблиц всегда работает медленнее и требует бОльших вычислительных ресурсов, нежели выборка из одной таблицы. К тому же когда имеется одна большая таблица - многие выборки легко оптимизируются индексами. Когда целая связка таблиц - этот вопрос решается гораздо менее эффективно (хотя казалось - везде также есть индексы).

Собственно - изменение архитектуры БД, частичная нормализация таблиц и привели к тому, что AX 2012 стала требовать (на демо-виртуалке) минимум 32 Гб, в то время, как для AX 2009 4 Гб хватало за глаза.

В D365FO в демо-виртуалке такого "взрывного роста" к требованиям уже не случилось, но надо понимать, что:
1. Структуру БД радикально уже не меняли
2. Убрали клиента, который использовал определенные ресурсы системы.
3. Скорость работы в системе при этом не увеличилась