Показать сообщение отдельно
Старый 05.09.2022, 07:30   #10  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,275 / 3476 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от twilight Посмотреть сообщение
Т. е. получается концепция наследования таблиц в целом нежизнеспособна?
Лично я считаю, что в той реализации, которая была сделана в АХ - да, нежизнеспособна. Да, такая вещь, как наследование методов может быть и удобна, но она легко (и с бОльшим удобством) может быть вынесена на иерархию классов. В остальном - пользы нет.

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

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

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