|
|
02.10.2019, 09:35
|
#1 |
|
Участник
|
Основная проблема - это справочники. Не очень понимаю, как в этой схеме будет осуществляться с ними работа?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
|
02.10.2019, 10:09
|
#2 |
|
Участник
|
Цитата:
Сообщение от sukhanchik
и система автоматически на уровне ядра будет дублировать эти записи в компаниях
можно я ничего не буду говорить о "дублировании"? о мертвых либо хорошо, либо ничего. Цитата:
Сообщение от Владимир Максимов
Не очень понимаю, как в этой схеме будет осуществляться с ними работа?
хороший вопрос. спасибо. надо подумать. добавлено: для 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 будет совпадать. Последний раз редактировалось mazzy; 02.10.2019 в 10:30. Причина: смотреть в сторону OpenDataSource |
|
|
|
03.10.2019, 14:59
|
#3 |
|
Участник
|
Цитата:
Сообщение от mazzy
все равно все справочники и/или документы - некий url, на котором "живет" сервис, принимающий запросы и отдающий данные.
сейчас dataAreaId - это параметр запроса. а можно для каждого справочника делать отдельный url.  Правильно ли я понимаю, что физически данные будут хранится примерно так 1. Документы - отдельная база данных для каждой компании 2. Справочники (номенклатуры, контрагенты и т.п.) - это еще одна база данных. Если справочники для каждой компании свои, то количество баз - увеличивается Ну, и какое-то взаимодействие между ними на уровне сервисов. А не приведет ли это к прямо противоположному эффекту в смысле увеличения нагрузки на SQL? Ведь одно дело простой Join и совсем другое некое взаимодействие сервисов. Прямое-то общение баз данных - невозможно будет. Т.е. работа со списками будет сильно затруднена.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
|
03.10.2019, 15:18
|
#4 |
|
Участник
|
Цитата:
Сообщение от Владимир Максимов
Правильно ли я понимаю, что физически данные будут хранится примерно так
1. Документы - отдельная база данных для каждой компании 2. Справочники (номенклатуры, контрагенты и т.п.) - это еще одна база данных. Если справочники для каждой компании свои, то количество баз - увеличивается Я имел в виду скорее деление по модулям/package, чем по типу информации. Согласен, что в своем посте написал не полностью. Сейчас в Аксапте огромная куча всего. Все таблицы в одной базе. Все компании в одной базе. Все tenants в одной базе. первое что приходит в голову - разные тенанты (в аксапте partitions) выделить на отдельные сервера в рамках kubernetes. второе что приходит в голову - разделить по функциональности. там чтобы wms был в своем сервисе и со своей оркестрацией, ритейлы - в своем, анкеты/hrm в своем... да, нужно очень крепко думать стоит ли разделять главную книгу, задолженности, склад... Но речь идет о принципиальной возможности и инструментарии. Для примера - валютные курсы. Совершенно отдельный функционал, маленькое хранилище, очень ограниченный функционал заполнения и импорта этих значений. нужен всем остальным модулям. Да, в Аксапте метод amount реализован на таблице Currency. но это совершенно не обязательно. третье что приходит в голову - и собственно это и есть тема данной ветки - компании тоже не обязательно вести в одной базе. ровно этот же механизм обращения к другой базе/сервису можно использовать и при обращении к другой компании. получается что в нынешнее время микросервисов и оркестров kubernetes совершенно не обязательно иметь всё в одной базе, как в 2000х. |
|
|
|
03.10.2019, 16:17
|
#5 |
|
Модератор
|
Цитата:
Сообщение от mazzy
разделить по функциональности. там чтобы wms был в своем сервисе и со своей оркестрацией, ритейлы - в своем, анкеты/hrm в своем
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
|
02.10.2019, 11:41
|
#6 |
|
Участник
|
Цитата:
Сообщение от Владимир Максимов
Основная проблема - это справочники. Не очень понимаю, как в этой схеме будет осуществляться с ними работа?
|
|
|
Комбинированный вид
