Доброго дня !
Тестирую 60 версию. Проблема производительности решена четко - в СГО не более 3 месяцев, в сервере магазина вообще один.
2 вопроса:
1) Как обмануть и держать хотя бы 2 года ? (изменение в табличке параметров не помогает)
2)Что делать с выгружаемым хмл ? Может есть готовое решение, с чего можно начать ?
как насчет сделать конвертер типа Стандартный экспорт 1,2,3 или 4(см. доку какой лучше подойдет)
сделать под него бд в мускуле
и пусть туда выгружается
может быть имеет смысл на другой машине это все сделать
тогда еще гранты надо, чтоб укм по сети достучался
по такой базе и аналитику можно строить и при необходимости поднять историю
Если честно - я совершенно не понимаю в данном вопросе Сервис Плюса. Три месяца на сго ещё можно КАК-ТО вытерпеть и использовать конвертеры или там репликацию.. Но почему всего 1 месяц на сервере магазина?? И !!!ДВЕ НЕДЕЛИ!!! на кассе!? ДВЕ НЕДЕЛИ!!!
В УКМ4 была замечательная, избыточная система трёхуровневая система защиты данных. Вылетела касса - спустим данные с магазина. Вылетел магазин - поднимем с касс. Вылетел СГО (тьфу-тьфу-тьфу) - поднимем наверх с магазинов. Сейчас этого преимущества нет. Да и попросту неудобно для хоть какой-то мало мальской аналитики. На СГО пускать народ тоже не хочется. Зачем его мучить запросами, если для выполнения запросов вполне достаточно продаж на одном магазине?
При всей этой экономии есть совершенно дурацкая табличка trm_in_discount_type_items, которая хранит информацию о скидках СО ВСЕХ МАГАЗИНОВ!!! Вот у нас например она бы могла быть ровно в 35 раз меньше, чем она есть сейчас. 300мб данных и 300мб индексов, если память не изменяет. Вместо 10мб+10мб. Таблица кстати используется в каждом чеке и не по разу. И кушает ещё полезную память у кэшей. И каждый день на неё реплецируются данные.
Я, наверное, далек от реального использования, раз не понимаю сути проблемы... Но зачем везде хранить по куче дублирующихся данных, если, как говорит Павел, лучше сделать одну и лить в нее все необходимые данные? И только ее и бекапить..