![]() |
#29 |
Member
|
Я, пожалуй, в общем случае соглашусь с mazzy на этот раз.
Описанная выше проблема на самом деле с высокой вероятностью является примером неудачного архитектурного решения. По идее, разрабатывая архитектуру решения, выполняющий роль архитектора должен осознавать и ограничения (зачеркнуто) особенности конкретной (ERP или прочей) системы, и потенциально возможные обороты (рост базы), и много других вещей. Возможно, нужно было сделать промежуточную систему для учета проводок магазинов, и загружать их в Аксапту в агрегированном виде. Возможно, нужно было сделать несколько "маленьких Аксапточек". Возможно, еще что-то (решение по данному вопросу зависит от требований заказчика). Вариант использования другой системы также уместен, как это кому-то м.б. не прискорбно услышать. Если уж принято решение работать с Аксаптой, то незачем ныть теперь, и обвинять кого-то другого (Микрософт и его закрытие склада, например). С позиции "Имеем то, что имеем"... IMHO... вариант Wamr правильный. В данном случае Аксапта есть ни что иное, как учетная система. Тогда имеет смысл выносить из нее аналитику наружу. Например, в ОЛАП. Кстати, старые DOSовские системы раньше так и работали. Была процедура закрытия года и переноса в архив. Правда, причины были тогда в другом, но суть такая же. ОЛАПа не было. Но, возможно, кто-то делал его вручную. Насколько такой вариант использования Аксапты правильный — вопрос отдельный. В данной ветке его опустим. Исходя из моей практики, самое козырное правило: "Заказчик всегда прав". Возможно, ему именно это и нужно было.
__________________
С уважением, glibs® |
|
Теги |
архивирование, полезное |
|
![]() |
||||
Тема | Ответов | |||
Принципы построения базы данных | 11 | |||
Утилиты для работы с журналом базы данных | 0 | |||
Размер базы | 13 | |||
Создание полной копии Приложения и базы | 5 | |||
Распределенные базы ???? | 19 |
|