Как аргументировать ведение учета в разрезе 1 учреждение = 1 область жанных
Всем привет.
Вопрос к тем, кто централизовал бюджетные конторы с помощью Облачная подсистема 1СФреш.
Как вы аргументируете заказчика, что система должна строится по принципу 1 учреждение = 1 область данных.
Уже достало отбиваться от аргументов "мы так привыкли" и заявлений местных админчиков, что RLS вполне норм.
Вопрос к тем, кто централизовал бюджетные конторы с помощью Облачная подсистема 1СФреш.
Как вы аргументируете заказчика, что система должна строится по принципу 1 учреждение = 1 область данных.
Уже достало отбиваться от аргументов "мы так привыкли" и заявлений местных админчиков, что RLS вполне норм.
Найденные решения
1. Разный состав расширений/доп.обработок.
2. RLS влияет на производительность.
3. RLS заставляет создавать на 1 профиль кучу групп доступа.
4. Работа с копиями. Дамп одной области выгрузить гораздо проще, чем дамп одной огромной области.
5. ОД довольно изолированы, и установка кривого расширения на одну ОД не влияет на другие ОД(хотя тут немного лукавлю, встречался и с таким, была ошибка платформы), т.е. в таком варианте если умрет какая-то одна ОД, ее из бэкапа восстанавливаем, остальные работают и даже не знают, что были проблемы.
6. Когда организаций 250+, можно разнести на разные ноды, т.е. горизонтальная масштабируемость. Можно особо крупные организации выносить на отдельные ноды, чтобы ни они, ни на них не влияли остальные.
7. При обновлениях ОД также обновляются независимо, и мелким учреждениям не нужно ждать, пока выполняются обработчики данных крупных учреждений.
Но минусы тоже есть:
1. НСИ, особенно при необходимости внедрения BI, придется унифицировать
2. Сводные оперативные отчеты тоже придется костылить, на данный момент с этим все сложно. Например, если бух ЦБ хочет сформировать какую-нибудь ОСВ по нескольким учреждениям.
3. Бухгалтеру ЦБ придется работать в куче ОД.
2. RLS влияет на производительность.
3. RLS заставляет создавать на 1 профиль кучу групп доступа.
4. Работа с копиями. Дамп одной области выгрузить гораздо проще, чем дамп одной огромной области.
5. ОД довольно изолированы, и установка кривого расширения на одну ОД не влияет на другие ОД(хотя тут немного лукавлю, встречался и с таким, была ошибка платформы), т.е. в таком варианте если умрет какая-то одна ОД, ее из бэкапа восстанавливаем, остальные работают и даже не знают, что были проблемы.
6. Когда организаций 250+, можно разнести на разные ноды, т.е. горизонтальная масштабируемость. Можно особо крупные организации выносить на отдельные ноды, чтобы ни они, ни на них не влияли остальные.
7. При обновлениях ОД также обновляются независимо, и мелким учреждениям не нужно ждать, пока выполняются обработчики данных крупных учреждений.
Но минусы тоже есть:
1. НСИ, особенно при необходимости внедрения BI, придется унифицировать
2. Сводные оперативные отчеты тоже придется костылить, на данный момент с этим все сложно. Например, если бух ЦБ хочет сформировать какую-нибудь ОСВ по нескольким учреждениям.
3. Бухгалтеру ЦБ придется работать в куче ОД.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
1. Разный состав расширений/доп.обработок.
2. RLS влияет на производительность.
3. RLS заставляет создавать на 1 профиль кучу групп доступа.
4. Работа с копиями. Дамп одной области выгрузить гораздо проще, чем дамп одной огромной области.
5. ОД довольно изолированы, и установка кривого расширения на одну ОД не влияет на другие ОД(хотя тут немного лукавлю, встречался и с таким, была ошибка платформы), т.е. в таком варианте если умрет какая-то одна ОД, ее из бэкапа восстанавливаем, остальные работают и даже не знают, что были проблемы.
6. Когда организаций 250+, можно разнести на разные ноды, т.е. горизонтальная масштабируемость. Можно особо крупные организации выносить на отдельные ноды, чтобы ни они, ни на них не влияли остальные.
7. При обновлениях ОД также обновляются независимо, и мелким учреждениям не нужно ждать, пока выполняются обработчики данных крупных учреждений.
Но минусы тоже есть:
1. НСИ, особенно при необходимости внедрения BI, придется унифицировать
2. Сводные оперативные отчеты тоже придется костылить, на данный момент с этим все сложно. Например, если бух ЦБ хочет сформировать какую-нибудь ОСВ по нескольким учреждениям.
3. Бухгалтеру ЦБ придется работать в куче ОД.
2. RLS влияет на производительность.
3. RLS заставляет создавать на 1 профиль кучу групп доступа.
4. Работа с копиями. Дамп одной области выгрузить гораздо проще, чем дамп одной огромной области.
5. ОД довольно изолированы, и установка кривого расширения на одну ОД не влияет на другие ОД(хотя тут немного лукавлю, встречался и с таким, была ошибка платформы), т.е. в таком варианте если умрет какая-то одна ОД, ее из бэкапа восстанавливаем, остальные работают и даже не знают, что были проблемы.
6. Когда организаций 250+, можно разнести на разные ноды, т.е. горизонтальная масштабируемость. Можно особо крупные организации выносить на отдельные ноды, чтобы ни они, ни на них не влияли остальные.
7. При обновлениях ОД также обновляются независимо, и мелким учреждениям не нужно ждать, пока выполняются обработчики данных крупных учреждений.
Но минусы тоже есть:
1. НСИ, особенно при необходимости внедрения BI, придется унифицировать
2. Сводные оперативные отчеты тоже придется костылить, на данный момент с этим все сложно. Например, если бух ЦБ хочет сформировать какую-нибудь ОСВ по нескольким учреждениям.
3. Бухгалтеру ЦБ придется работать в куче ОД.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот