AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 02.10.2019, 08:40   #1  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,982 / 3868 (186) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
dataAreaId не нужен?
Механизм деления данных по компаниям - ключевое отличие Аксапты от других систем.

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

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

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

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

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

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

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

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

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

какие плюсы/минусы я пропустил и видите вы?
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 02.10.2019, 09:34   #2  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,731 / 2387 (85) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
в последних версиях Майкрософт полностью удалил виртуальные компании.
"Король умер, да здравствует король"
Не отвечая на вопрос (ответ требует некоторого продумывания) скажу лишь, что хотя механизм виртуальных компаний и был удален, но на смену ему пришел механизм
Cross company data sharing, суть которого состоит в том, что можно в настройке задать общие между компаниями таблицы (предполагается, что справочники) и система автоматически на уровне ядра будет дублировать эти записи в компаниях. Единственное ограничение - там нельзя использовать таблицы из групп Transaction, Main и Worksheet*. Но это ограничение условное - если в коде временно убрать запрет например, на группу Main - то CustTable / VendTable легко "расшариваются" между компаниями (после создания настройки - расширение можно удалить, но механизм будет работать).

Из плюсов перед виртуальными компаниями - нет необходимости делать хитрые джойны с разными dataareaid, т.к. записи дублируются, т.о. все выборки могут быть сделаны в рамках одной компании, а за синхронизацией данных следит ядро
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: Logger (3).
Старый 02.10.2019, 09:35   #3  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,440 / 954 (34) +++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Основная проблема - это справочники. Не очень понимаю, как в этой схеме будет осуществляться с ними работа?
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 02.10.2019, 10:09   #4  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,982 / 3868 (186) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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 будет совпадать.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.

Последний раз редактировалось mazzy; 02.10.2019 в 10:30. Причина: смотреть в сторону OpenDataSource
Старый 02.10.2019, 11:41   #5  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
447 / 239 (8) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Основная проблема - это справочники. Не очень понимаю, как в этой схеме будет осуществляться с ними работа?
Можно использовать MDM (НСИ).
Старый 02.10.2019, 15:14   #6  
trud is offline
trud
Участник
Лучший по профессии 2017
 
780 / 1010 (35) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Ты сразу начал со сложного. Давай сначала обсудим зачем нужен столбец PARTITION
Старый 02.10.2019, 15:19   #7  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,982 / 3868 (186) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от trud Посмотреть сообщение
Давай сначала обсудим зачем нужен столбец PARTITION
PARTITION уже выкинули вроде.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 02.10.2019, 15:55   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,233 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от mazzy Посмотреть сообщение
PARTITION уже выкинули вроде.
Кстати, его можно в 2012-й отключить для всех таблиц через настройку, как DataAreaId (-internal = nodataareaId)?
Старый 02.10.2019, 16:03   #9  
trud is offline
trud
Участник
Лучший по профессии 2017
 
780 / 1010 (35) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Когда его выкинули? Живет и входит в любой индекс
Старый 03.10.2019, 14:59   #10  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,440 / 954 (34) +++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
все равно все справочники и/или документы - некий url, на котором "живет" сервис, принимающий запросы и отдающий данные.
сейчас dataAreaId - это параметр запроса.
а можно для каждого справочника делать отдельный url.
Да, да. Меняем неправильное "шило", на идеологические верное "мыло"

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

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

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

А не приведет ли это к прямо противоположному эффекту в смысле увеличения нагрузки на SQL? Ведь одно дело простой Join и совсем другое некое взаимодействие сервисов. Прямое-то общение баз данных - невозможно будет. Т.е. работа со списками будет сильно затруднена.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 03.10.2019, 15:18   #11  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,982 / 3868 (186) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Правильно ли я понимаю, что физически данные будут хранится примерно так

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

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

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

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

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

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

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

получается что в нынешнее время микросервисов и оркестров kubernetes совершенно не обязательно иметь всё в одной базе, как в 2000х.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 03.10.2019, 15:56   #12  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,233 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
На хабре была интересная статья.
https://habr.com/ru/post/414269/

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

Как один из вариантов решения предлагалось разбиение базы на 2. (Как я понимаю, например, одна продажи, другая WMS) Идея в том что у каждой базы свой лог и при одинаковом Latency общая производительность может получиться выше. Вывод несколько парадоксальный и его надо еще поосмыслить. А может и оспорить.
В комментариях там тоже интересные вопросы и обсуждения.
Старый 03.10.2019, 16:17   #13  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,439 / 1560 (59) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от mazzy Посмотреть сообщение
разделить по функциональности. там чтобы wms был в своем сервисе и со своей оркестрацией, ритейлы - в своем, анкеты/hrm в своем
ага, по четным - разделяем, по нечетным - интегрируем через CDS
__________________
-ТСЯ или -ТЬСЯ ?
Старый 03.10.2019, 16:44   #14  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,359 / 305 (13) ++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Честно говоря, я с трудом представляю себе разделение БД на куски ради модулей. Отдельные функциональные блоки достаточно плотно взаимодействуют друг с другом (в заказах на продажу есть ссылки на работников, к примеру). Выделять в отдельные сервисы есть смысл только что-то совсем уж автономное. Но я такого не вижу. Те же валютные курсы используют таблицу валют, которая ещё много где нужна - как же их инкапсулировать в сервис?
__________________
С уважением,
Вячеслав
Старый 03.10.2019, 17:16   #15  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,982 / 3868 (186) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от pitersky Посмотреть сообщение
Те же валютные курсы используют таблицу валют, которая ещё много где нужна
...на чтение!

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

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

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

с точки зрения СУБД есть механизмы подписки и кэширования.
ну и код совершенно не обязан каждый раз физически дергать внешнюю СУБД или сервис за импортируемым функционалом
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 04.10.2019, 10:01   #16  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,440 / 954 (34) +++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Тема "Монолит vs Сервис" уже неоднократно в разных видах поднималась. Но обычно в некоем "общем" виде и до конкретики "не опускались"

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

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

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

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

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

Не понимаю. Как?
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: EVGL (3).
Старый 04.10.2019, 11:16   #17  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,843 / 2369 (86) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если же речь идет о вполне конкретном поле DataAreaId, то я не понимаю вполне себе конкретной проблемы. Справочники.
Вы подняли очень правильную тему. Подход Microsoft - это CDS. С учетом того, что оно до сих пор работает через пень-колоду, а то и только в этом месяце будет обновлено до версии, которую реально можно применять на практике -
https://docs.microsoft.com/en-us/bus...a-service-apps
- то трудозатраты и технические сложности очевидно велики. Ну и как обычно: любой интерфейс имеет свойство регулярно ломаться.
Старый 04.10.2019, 13:04   #18  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,233 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
1. Справочники носят сугубо "внутренний" характер. Т.е ведутся только и исключительно внутри Axapta
2. Записи могут быть как связаны с конкретной компанией, так и быть общими для всех компаний
3. Необходимо иметь возможность сопоставить записи разных компаний для консолидированных отчетов
На одном из проектов в 2009-й аксапте был написан движок по репликации справочников.

Если коротко, то InventTable / InventTableModule во всех компаниях был одинаков. При создании записи в компании раскопировался везде. При обновлении - в зависимости от настроек поля. По каждому полю можно было настроить куда оно копируется. В принципе можно задачу обобщить когда все живет не в одной базе а в разных.
Старый 04.10.2019, 13:44   #19  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,440 / 954 (34) +++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Ну, я понимаю, как чисто технически это можно сделать. Даже несколько вариантов вижу.

Но основной-то посыл в теме был "давайте упростим и сэкономим". И вот не вижу я этой самой экономии и упрощения. Усложнение во всех смыслах - есть. Экономии - нет. Или я чего-то не замечаю?
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: EVGL (3).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Для форума нужен дизайнер. mazzy Обсуждение форума 1 28.07.2009 13:38
Нужен сосед программист DAX для Совместного съема жилья :) Andrew Akhmetov Курилка 28 25.11.2008 17:53
'Мама, зачем нужен это сервер?' (с) Microsoft belugin Курилка 13 01.02.2008 20:34
Опрос: Одобрение и репутация: Нужен ли прогрессирующий коэффициент? sukhanchik Обсуждение форума 2 15.02.2006 09:42
Нужен ли нам профсоюз? George Nordic Курилка 38 21.06.2004 13:06
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 21:27.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.