dataAreaId не нужен?

[mazzy]

Механизм деления данных по компаниям - ключевое отличие Аксапты от других систем.

вкратце:

1. разработчик может каждую таблицу объявить общей, а может указать что таблица содержит данные по компаниям.
2. если объявлено, что таблица содержит данные по компаниям, то Аксапта автоматически добавляет поле dataAreaId в таблицу. В дальнейшем Аксапта в любой запрос автоматически добавляет фильтр по этому полю.
3. консультант на этапе разработки (в классических версиях Аксапты) может включить таблицу в так называемые "виртуальные компании". В этом случае Аксапта записывает/запрашивает в поле dataAreaId не текущую компанию, в которую зашел пользователь, а так называемую "виртуальную". что позволяло использовать не только данные по компаниям, но общие для нескольких компаний данные.

вроде механизм хороший. я не буду приводить плюсы/минусы. отмечу только, что в последних версиях Майкрософт полностью удалил виртуальные компании.

что хотелось бы спросить/обсудить:
кажется, что в современных условиях (докеры, кубернетики и прочие облака) механизм избыточный и слишком нагружающий и SQL server и разработчика.

современное приложение - скорее всего не монолит, а набор REST-овидных сервисов для доступа к данным. причем данные могут хранится у разных провайдеров данных (sql, nosql, несколько инстансов данных).

в этих условиях для каждой компании лучше развернуть свой сервис.
а запрос к "другой компании" должен выглядеть как запрос к "другому сервису".
причем общие для нескольких компаний данные - это просто общий для нескольких компаний сервис.

автоматически получаем авторизацию при запросе "другого сервиса".

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

чтобы создать "документ" в другой компании, нужно обратиться к сервису другой компании.

плюсы: распараллеливание и масштабируемость, нет принудительной вставки условия в запросы - проще администрирование и разработка.
минусы: производительность, транзационность "интеркомпани" операций

какие плюсы/минусы я пропустил и видите вы?

[sukhanchik]

Цитата:

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

в последних версиях Майкрософт полностью удалил виртуальные компании.

"Король умер, да здравствует король"
Не отвечая на вопрос (ответ требует некоторого продумывания) скажу лишь, что хотя механизм виртуальных компаний и был удален, но на смену ему пришел механизм
Cross company data sharing, суть которого состоит в том, что можно в настройке задать общие между компаниями таблицы (предполагается, что справочники) и система автоматически на уровне ядра будет дублировать эти записи в компаниях. Единственное ограничение - там нельзя использовать таблицы из групп Transaction, Main и Worksheet*. Но это ограничение условное - если в коде временно убрать запрет например, на группу Main - то CustTable / VendTable легко "расшариваются" между компаниями (после создания настройки - расширение можно удалить, но механизм будет работать).

Из плюсов перед виртуальными компаниями - нет необходимости делать хитрые джойны с разными dataareaid, т.к. записи дублируются, т.о. все выборки могут быть сделаны в рамках одной компании, а за синхронизацией данных следит ядро

[Владимир Максимов]

Основная проблема - это справочники. Не очень понимаю, как в этой схеме будет осуществляться с ними работа?

[mazzy]

Цитата:

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

и система автоматически на уровне ядра будет дублировать эти записи в компаниях

угу.
можно я ничего не буду говорить о "дублировании"? о мертвых либо хорошо, либо ничего.

Цитата:

Сообщение от Владимир Максимов

Не очень понимаю, как в этой схеме будет осуществляться с ними работа?

работа на уровне SQL-запросов? чтобы сджойнить данные?

хороший вопрос. спасибо. надо подумать.
добавлено: для MS SQL, скорее всего, стоит посмотреть в сторону OPENDATASOURCE, OPENROWSET, OPENQUERY
добавлено 2: для PostgreSQL - в сторону dblink_fetch

в исходном вопросе я говорил не о SQL-запросах, а про обращение к REST-сервисам провайдеров данных.

все равно все справочники и/или документы - некий url, на котором "живет" сервис, принимающий запросы и отдающий данные.
сейчас dataAreaId - это параметр запроса.
а можно для каждого справочника делать отдельный url.

например, валюты по странам:
currency.company.ru/...
currency.company.ua/...
currency.company.kz/...

и заказы по филиалам:
salesorder.msk.company.ru/...
salesorder.spb.company.ru/...
salesorder.nsk.company.ru/...
salesorder.kiev.company.ua/...
salesorder.company.kz/...

каждый филиал обращается за валютой к своей стране, а не к своему домену.
естественно, в каждом филиале придется настраивать url для каждого справочника. для большинства справочников url будет совпадать.

[Alexius]

Цитата:

Сообщение от Владимир Максимов

Основная проблема - это справочники. Не очень понимаю, как в этой схеме будет осуществляться с ними работа?

Можно использовать MDM (НСИ).

[trud]

Ты сразу начал со сложного. Давай сначала обсудим зачем нужен столбец PARTITION

[mazzy]

Цитата:

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

Давай сначала обсудим зачем нужен столбец PARTITION

PARTITION уже выкинули вроде.

[Logger]

Цитата:

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

PARTITION уже выкинули вроде.

Кстати, его можно в 2012-й отключить для всех таблиц через настройку, как DataAreaId (-internal = nodataareaId)?

[trud]

Когда его выкинули? Живет и входит в любой индекс

[Владимир Максимов]

Цитата:

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

все равно все справочники и/или документы - некий url, на котором "живет" сервис, принимающий запросы и отдающий данные.
сейчас dataAreaId - это параметр запроса.
а можно для каждого справочника делать отдельный url.

Да, да. Меняем неправильное "шило", на идеологические верное "мыло"

Правильно ли я понимаю, что физически данные будут хранится примерно так

1. Документы - отдельная база данных для каждой компании
2. Справочники (номенклатуры, контрагенты и т.п.) - это еще одна база данных. Если справочники для каждой компании свои, то количество баз - увеличивается

Ну, и какое-то взаимодействие между ними на уровне сервисов.

А не приведет ли это к прямо противоположному эффекту в смысле увеличения нагрузки на SQL? Ведь одно дело простой Join и совсем другое некое взаимодействие сервисов. Прямое-то общение баз данных - невозможно будет. Т.е. работа со списками будет сильно затруднена.

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Правильно ли я понимаю, что физически данные будут хранится примерно так

1. Документы - отдельная база данных для каждой компании
2. Справочники (номенклатуры, контрагенты и т.п.) - это еще одна база данных. Если справочники для каждой компании свои, то количество баз - увеличивается

Не совсем.

Я имел в виду скорее деление по модулям/package, чем по типу информации.
Согласен, что в своем посте написал не полностью.

Сейчас в Аксапте огромная куча всего. Все таблицы в одной базе. Все компании в одной базе. Все tenants в одной базе.

первое что приходит в голову - разные тенанты (в аксапте partitions) выделить на отдельные сервера в рамках kubernetes.

второе что приходит в голову - разделить по функциональности. там чтобы wms был в своем сервисе и со своей оркестрацией, ритейлы - в своем, анкеты/hrm в своем... да, нужно очень крепко думать стоит ли разделять главную книгу, задолженности, склад... Но речь идет о принципиальной возможности и инструментарии.

Для примера - валютные курсы. Совершенно отдельный функционал, маленькое хранилище, очень ограниченный функционал заполнения и импорта этих значений. нужен всем остальным модулям. Да, в Аксапте метод amount реализован на таблице Currency. но это совершенно не обязательно.

третье что приходит в голову - и собственно это и есть тема данной ветки - компании тоже не обязательно вести в одной базе. ровно этот же механизм обращения к другой базе/сервису можно использовать и при обращении к другой компании.

получается что в нынешнее время микросервисов и оркестров kubernetes совершенно не обязательно иметь всё в одной базе, как в 2000х.

[Logger]

На хабре была интересная статья.
https://habr.com/ru/post/414269/

в которой утверждалось, что при высокой OLTP нагрузки узким местом может стать latency системы хранения данных. Все упирается в быстроту отклика при записи в лог транзакций.

Как один из вариантов решения предлагалось разбиение базы на 2. (Как я понимаю, например, одна продажи, другая WMS) Идея в том что у каждой базы свой лог и при одинаковом Latency общая производительность может получиться выше. Вывод несколько парадоксальный и его надо еще поосмыслить. А может и оспорить.
В комментариях там тоже интересные вопросы и обсуждения.

[Vadik]

Цитата:

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

разделить по функциональности. там чтобы wms был в своем сервисе и со своей оркестрацией, ритейлы - в своем, анкеты/hrm в своем

ага, по четным - разделяем, по нечетным - интегрируем через CDS

[pitersky]

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

[mazzy]

Цитата:

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

Те же валютные курсы используют таблицу валют, которая ещё много где нужна

...на чтение!

таблица валют нужна на чтение.
стоит проговорить фразу до конца - сразу становится понятно

создание, импорт и ввод курсов, кросс-курсы, формы ввода, права и роли пользователей для ввода в остальных модулях не нужны.

Цитата:

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

как же их инкапсулировать в сервис?

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

с точки зрения СУБД есть механизмы подписки и кэширования.
ну и код совершенно не обязан каждый раз физически дергать внешнюю СУБД или сервис за импортируемым функционалом

[Владимир Максимов]

Тема "Монолит vs Сервис" уже неоднократно в разных видах поднималась. Но обычно в некоем "общем" виде и до конкретики "не опускались"

Если же речь идет о вполне конкретном поле DataAreaId, то я не понимаю вполне себе конкретной проблемы. Справочники.

С мелкими справочниками, вроде валют, единиц измерения и т.п. все понятно. Эти справочники носят "глобальный" характер и, по большому счету, ведутся (сопровождаются) вообще вне Axapta. Т.е. слабо зависят не только от DataAreaId, но и от Axapta вообще.

Нет, теоретически, конечно, возможно, что, например, в компании "А" для валюты "руб" настроят округление до 2 знаков после запятой, а для компании "Б" - до целого. Но, на практике - сильно сомнительно...

А вот что делать с "большими" справочниками вроде номенклатур, поставщиков и клиентов для которых

1. Справочники носят сугубо "внутренний" характер. Т.е ведутся только и исключительно внутри Axapta
2. Записи могут быть как связаны с конкретной компанией, так и быть общими для всех компаний
3. Необходимо иметь возможность сопоставить записи разных компаний для консолидированных отчетов

Не понимаю. Как?

[EVGL]

Цитата:

Сообщение от Владимир Максимов

Если же речь идет о вполне конкретном поле DataAreaId, то я не понимаю вполне себе конкретной проблемы. Справочники.

Вы подняли очень правильную тему. Подход Microsoft - это CDS. С учетом того, что оно до сих пор работает через пень-колоду, а то и только в этом месяце будет обновлено до версии, которую реально можно применять на практике -
https://docs.microsoft.com/en-us/bus...a-service-apps
- то трудозатраты и технические сложности очевидно велики. Ну и как обычно: любой интерфейс имеет свойство регулярно ломаться.

[Logger]

Цитата:

Сообщение от Владимир Максимов

1. Справочники носят сугубо "внутренний" характер. Т.е ведутся только и исключительно внутри Axapta
2. Записи могут быть как связаны с конкретной компанией, так и быть общими для всех компаний
3. Необходимо иметь возможность сопоставить записи разных компаний для консолидированных отчетов

На одном из проектов в 2009-й аксапте был написан движок по репликации справочников.

Если коротко, то InventTable / InventTableModule во всех компаниях был одинаков. При создании записи в компании раскопировался везде. При обновлении - в зависимости от настроек поля. По каждому полю можно было настроить куда оно копируется. В принципе можно задачу обобщить когда все живет не в одной базе а в разных.

[Владимир Максимов]

Ну, я понимаю, как чисто технически это можно сделать. Даже несколько вариантов вижу.

Но основной-то посыл в теме был "давайте упростим и сэкономим". И вот не вижу я этой самой экономии и упрощения. Усложнение во всех смыслах - есть. Экономии - нет. Или я чего-то не замечаю?