Вот мы и нашли этих 43 AX7 клиентов? Или это не AX7/D365?

[macklakov]

Цитата:

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

Все кастомные поля в отдельную таблицу, связь по RecId c базовой таблицей. Такой подход продолжает работать для D365.

А потом приходится устраивать пляски с бубном вокруг SQL чтобы он отрабатывал запросы в 30 таблиц в более-менее вменяемое время. И это без XDS, которую любой консультант спомощью галочки может активировать. С другой стороны, это извечная дилемма мира AX:"как совместить удобство Office с мощью SAP"

[AlexSD]

Цитата:

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

А потом приходится устраивать пляски с бубном вокруг SQL чтобы он отрабатывал запросы в 30 таблиц в более-менее вменяемое время.

Не думаю, что прям вот так сразу от одной дополнительной таблицы для одного ISV легко получится переступить порог в эти 30 таблиц сразу для всех стандартных форм.

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

Короче, это не та причина, что бы перестать создавать свои таблицы.

[macklakov]

Цитата:

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

Не думаю, что прям вот так сразу от одной дополнительной таблицы для одного ISV легко получится переступить порог в эти 30 таблиц сразу для всех стандартных форм.

Почему же только для одной? И почему только одного ISV рассматриваем? Ну и все стандартные формы корежить не обязательно. Хватит и парочки чтобы пользователи взвыли.

Цитата:

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

Например, для тех форм, где уже есть 25-29 таблиц

Ну вот давай рассмотрим сценарий:
На стандартной форме 24 таблице в join.
Устанавливается 2 решения от 2-х разных ISV. Каждое из решений добавляет по 3 таблицы.
В очередно релизе MS решает накинуть еще несколько табличек. Часто для системных нужд. Рефакторинг, нормализация, шаблоны проектирования и все такое.
И не забываем что типичный консультант свято уверен что врубить флажок secure by legal entity в параметрах GAB логичное решение. Ведь это стандарт и в доках его рекомендуют использовать.
Так вот, сколько у нас в результате таблиц в запросе получится?
P.S. Нет, я согласен, что концепция красивая и в любом случае "все там будем", но есть у меня ощущение что граблей тут разбросано изрядно. Топтать и топтать.

[AlexSD]

Цитата:

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

Почему же только для одной? И почему только одного ISV рассматриваем?

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

То, что ты описываешь, больше похоже на ISV с ненулевым оверлеингом, которое расширяет существующий функционал оверлея его на все 100%.

В случае, когда на форме уже есть 24 таблицы, я бы, как вендор ISV, такую форму не полез бы со своими таблицами. Прилепил бы поля на новую форму и повесил бы ее куда-нибудь на кнопку.