Механизм деления данных по компаниям - ключевое отличие Аксапты от других систем.
вкратце:
- разработчик может каждую таблицу объявить общей, а может указать что таблица содержит данные по компаниям.
- если объявлено, что таблица содержит данные по компаниям, то Аксапта автоматически добавляет поле dataAreaId в таблицу. В дальнейшем Аксапта в любой запрос автоматически добавляет фильтр по этому полю.
- консультант на этапе разработки (в классических версиях Аксапты) может включить таблицу в так называемые "виртуальные компании". В этом случае Аксапта записывает/запрашивает в поле dataAreaId не текущую компанию, в которую зашел пользователь, а так называемую "виртуальную". что позволяло использовать не только данные по компаниям, но общие для нескольких компаний данные.
вроде механизм хороший. я не буду приводить плюсы/минусы. отмечу только, что в последних версиях Майкрософт полностью удалил виртуальные компании.
что хотелось бы спросить/обсудить:
кажется, что в современных условиях (докеры, кубернетики и прочие облака) механизм избыточный и слишком нагружающий и SQL server и разработчика.
современное приложение - скорее всего не монолит, а набор REST-овидных сервисов для доступа к данным. причем данные могут хранится у разных провайдеров данных (sql, nosql, несколько инстансов данных).
в этих условиях для каждой компании лучше развернуть свой сервис.
а запрос к "другой компании" должен выглядеть как запрос к "другому сервису".
причем общие для нескольких компаний данные - это просто общий для нескольких компаний сервис.
автоматически получаем авторизацию при запросе "другого сервиса".
чтобы получить сводный отчет по "холдингу", нужно сделать union запросов по разным компаниям.
чтобы создать "документ" в другой компании, нужно обратиться к сервису другой компании.
плюсы: распараллеливание и масштабируемость, нет принудительной вставки условия в запросы - проще администрирование и разработка.
минусы: производительность, транзационность "интеркомпани" операций
какие плюсы/минусы я пропустил и видите вы?