Существуют ли механизмы свертывания базы?

[Zabr]

Цитата:

Сообщение от sergeypp

А в пределах темы

Найти количество записей InventTrans для каждой записи из InventSum - по каким полям связка??

видимо по ItemId && inventDimId

[Yprit]

Цитата:

Сообщение от sergeypp

И еще сразу вопрос.. за год прирост 160 Гиг.. еще терпимо, а что делать через 3 года?
Существуют ли решения, при которых одна база сворачивалась и настройки переносились в новую с первоначальными остатками.. само собой историю за прошлый период смотрят в старой базе?.. я конечно понимаю.. что многое полетит, но как вариант "лекарства" возможно?.. еще раз повторяюсь .. реализовывался ли такой вариант?

На Аксапте такого пока не делали - делали на Эске, причем не раз
Мне почему-то кажется, что в Вашем случае надо посмотреть на алгоритмы - 160 гигов за год многовато все-таки....

[Zabr]

Цитата:

Сообщение от Yprit

в Вашем случае надо посмотреть на алгоритмы - 160 гигов за год многовато все-таки....

Как-то потерялось, что 160 Гб в год - это не текущий прирост, а экстраполяция sergeypp на случай, когда магазинов будет 500. А сейчас их 42. Т.е. сейчас прирост составил бы всего 13 Гб в год.

[Yprit]

Цитата:

Сообщение от Zabr

Как-то потерялось, что 160 Гб в год - это не текущий прирост, а экстраполяция sergeypp на случай, когда магазинов будет 500. А сейчас их 42. Т.е. сейчас прирост составил бы всего 13 Гб в год.

Да, точно, увлекся

[mazzy]

Цитата:

Сообщение от sergeypp

2 Mazzy
Вот список лидеров.

PHP код:

INVENTTRANS    1092424
SALESLINE    378704
LEDGERTRANS    368968
CUSTINVOICETRANS    289360
INVENTTRANSPOSTING    279896
INVENTSUM    260384
FACTURETRANS_RU    236024
TAXTRANS    197192
INVENTJOURNALTRANS    141784
CUSTCONFIRMTRANS    133688
LEDGERJOURNALTRANS    123232
CUSTINVOICEJOUR    94584
CUSTTRANS    86792
SALESTABLE    77912
... 


Мдя... С InventTrans, LedgerTrans особо ничего не поделаешь...
У складских проводок InventTrans есть стандартная процедура свертки.
Ее можно найти в окне проводок, кнопка Функции, Суммирование.
Но в ней объединяются записи в пределах одного лота.

Плохо то, что вы храните старые заказы (SalesTable, SalesLine) и журналы (LedgerJournalTrans).
Но по этим таблицам у ритейла может быть модификация, которая требует, чтобы заказы и журналы не удалялись. Надо проверить. В стандартном функционале Заказы и Журналы - черновики, которые можно удалить после разноски (у журналов и заказов даже галочки соответсвующие есть).

В общем то наиболее хитовыми являются таблицы, которые содержат проводки.
Эти таблицы нельзя удалять.

Непосредственный способ работы с такими таблицами - сегментировать в SQL.
Сегменты со старыми данными переносить на более медленные (и дешевые диски)

[EVGL]

А что скажет Wamr? Он, кажется, имел непосредственное отношение к "Перекрестку". При упоминании InventTrans волоски на шее у него должны вставать дыбом (извините за поэтическое сравнение).

А в версии 5.0 обещают архивирование данных. Как раз в случае InventTrans и LedgerTrans такое легко представить. Т.е. экстраполировать можно только до 2008 (2009-го ?) года.

[sergeypp]

Цитата:

Сообщение от mazzy

Непосредственный способ работы с такими таблицами - сегментировать в SQL.
Сегменты со старыми данными переносить на более медленные (и дешевые диски)

Это, насколько я понимаю, толкько в 2005 MSSQL//

[TasmanianDevil]

Цитата:

Сообщение от EVGL

А в версии 5.0 обещают архивирование данных. Как раз в случае InventTrans и LedgerTrans такое легко представить.

Сальдо будут нормальное хранить , а не агрегированные обороты по проводкам ГК?

[Wamr]

Ну раз спросили, то отвечу
В Перекрестке Аксапта использовалась без финансового модуля, то есть проводки были, но никто их не смотрел, так что эта часть чистилась очень просто.
Сокращение InventTrans делалось созданием новой базой с переносом остатков на дату (с сохранением соотношения открытые-закрытые).
Процесс выглядил примерно так:
1. Перед полной инвентаризацией в обязательном порядке закрываются все "зависшие" документы, вычищаются "повисшие" проводки (не продано-приобретено и не заказано- в заказе)
2. Создается новая база, в которую заливаются мастер-данные, открытые документы (с проводками заказано-в заказе)
3. После подсчета (до разноски или параллельно разноске журналов) в новой базе создаются приходные проводки с типом перенос и "красивым" номером по количествам, аналитикам из журналов инвентаризации и средней себестоимостью.
4. Переносятся все InventDim, которые используются в новой базе и все партии которые используются в этих аналитиках.
5. Новая Аксапта запускается ... ночь прошла! ура! домой!
6. После закрытия периода в старой базе, в новой создается приходная накладная (либо стандартно, либо генерация записей своей процедурой) на резервный склад с правильной суммой и создаются расходные проводки с "красивым" журналом переноса с резервного склад со старой себестоимостью. (Создание приходной накладной на несколько тысяч строк - отдельная большая тема)
7. Часть приходных проводок "закрывается" для сопоставления. Можно было бы и помельче подробить для сохранения ФИФО, но это оказалось никому не нужно.

Делается в инвентаризацию, так как система в это время не работает, остатки после инвентаризации близки к реальности, все аналитики старого резервного склада становятся неактуальными и не переносятся.

[sergeypp]

2 Wamr
Мдаааааааа......но в любом случае как вариант..
накатились воспоминания, как я в наве одну фирму другой продавал.. там тоже.. Ура. ночь прошла.. только вот домой не уходил)))

[komar]

Цитата:

Сообщение от Wamr

Ну раз спросили, то отвечу

Эту процедуру делали ежегодно или чаще?

[mazzy]

Цитата:

Сообщение от sergeypp

но в любом случае как вариант..

Категорически против такого варианта.
Только если остальные варианты не подходят.

[Wamr]

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

[glibs]

Я, пожалуй, в общем случае соглашусь с mazzy на этот раз.

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

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

Если уж принято решение работать с Аксаптой, то незачем ныть теперь, и обвинять кого-то другого (Микрософт и его закрытие склада, например).

С позиции "Имеем то, что имеем"... IMHO... вариант Wamr правильный. В данном случае Аксапта есть ни что иное, как учетная система. Тогда имеет смысл выносить из нее аналитику наружу. Например, в ОЛАП.

Кстати, старые DOSовские системы раньше так и работали. Была процедура закрытия года и переноса в архив. Правда, причины были тогда в другом, но суть такая же. ОЛАПа не было. Но, возможно, кто-то делал его вручную.

Насколько такой вариант использования Аксапты правильный — вопрос отдельный. В данной ветке его опустим. Исходя из моей практики, самое козырное правило: "Заказчик всегда прав". Возможно, ему именно это и нужно было.

[sergeypp]

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

[glibs]

Существуют, конечно.

Я видел как минимум одну такую (я к внедрению никакого отношения не имел). Правда, в регионах были отдельные юрлица и отдельные базы. Из центра текла номенклатура и еще что-то. подробностей не помню. Назад собирались остатки номенклатуры в режиме остаток на дату (т.е. проводки не передавались). Остальное тоже не помню уже. Обмен был в .CSV. Много было реализовано функциональности а-ля Intercompany. Взаимоотношения центр-регион были купля-продажа.

Работало надежно.

Так что вот...

[mazzy]

Цитата:

Сообщение от glibs

Существуют, конечно.

...

Работало надежно.

Существуют, но надежного, быстрого и универсального решения я не видел.
Если glibs имеет в виду того, кого я тоже знаю, то у них репликация делалась очень-очень-очень долго.

В конце концов так и остались трудности с резервированием товара на центральном складе (особенно дефицитного товара). А процедура создания товара превратилась в отдельный скриптовый язык.

Основные проблемы:
1. Обеспечить целостность справочной информации (один и тот же товар вводится в разных точках, а также удаляется/редактируется).
2. Обеспечить двухфазную фиксацию транзакции в распределенной среде (филиалы имеют реплики остатков центрального склада, заказывают дефицитный товар, в репликах транзакция завершена, а после обмена в центральной базе транзакция одного из филиалов не прошла. Что делать?)

В общем, тот еще гемор.
Повторю только одно: разработчики решили, что организовать постоянный канал к единой базе дешевле, нежели заниматься конфликтами репликации. Во многих случаях это правильное решение.

Вопрос с репликацией обсуждался неоднократно.

[sergeypp]

И все таки.. неужели нельзя свернуть тот же самый inventtrans за опред период.. не удалять а просуммировать строки. приделать к ним новое измерение(Допустим в разрезе склада - ячейка и гтд свернуть). В итоге вместо 5 тыс строк получим 2 строки. и отчеты поплыть не должны.. ? неужели так никто не делал

[Serge Kotov]

Цитата:

Сообщение от glibs

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

А существенной проблемы с ростом БД в Перекрестке собственно говоря и нет благодаря варианту Wamrа. Пусть некрасив способ внешне, но работает и успешно применяется.

[Zabr]

Цитата:

Сообщение от Serge Kotov

Пусть некрасив способ внешне, но работает и успешно применяется.

Большой вопрос, применим ли этот способ для поднявшего тему Sergeypp. Как я понимаю, в Перекрестке 1 (один) склад - распределительный центр (РЦ), и его инвентаризация позволяет освободить базу для таких рабаот. А Sergeypp - 42 магазина-склада, наверное еще и РЦ есть. Это значит, что нужно останавливать на 1-2-3 дня весь бизнес.