Цитата:
Сообщение от
Logger
я немного разочарован - ожидал что производительность улучшится за счет сокращения объема операций ввода вывода
Vardecimal storage стоит рассматривать прежде всего как средство уменьшить использование дискового пространства при минимальных накладных расходах. Влияние на производительность стоит рассматривать скорее как побочный эффект, тем более что для разных систем оно будет разным. Да, IO
теоретически может улучшиться, однако нагрузка на процессор увеличится хоть и незначительно, но гарантированно. Конечный результат будет зависеть от того, что в данный момент является узким местом системы.
Цитата:
Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?
Применять можно везде, так как накладные расходы невелики. В случае OLTP просто нужно учитывать некоторые моменты
Цитата:
Если применять к Аксапте, то для каких таблиц ?
Редко обновляемые большие таблицы (строки журналов, заказов, закупок) ?
Часто обновляемые большие таблицы с большим количеством числовых полей (InventSum)?
Ну, журналы я скорее предпочту чистить, нежели сжимать. Знаю, что выглядит немного радикально
Знаю, что не всегда возможно (например, локализованные отчеты построенные на складских журналах)
INVENTSUM - скорее всего нет. Даже при использовании партий, палет и серийных номеров размер таблицы недостаточно велик, чтобы при включении VARDECIMAL получить хоть какую-то значимую экономию дискового пространства. Кроме того, при высокой частоте обновления (UPDATE) повышается вероятность того, что ранее "сжатая" запись должна "разжаться" (новое значение требует большей размерности по сравнению со старым) и на странице не свободного места, что ведет либо к расщеплению страницы, либо к появлению forwarded record (все это описано в whitepaper по ссылке, которую я привел)
INVENTTRANS, INVENTSETTLEMENT, LEDGERTRANS - тут выигрыш в занимаемом таблицей пространстве имеет место быть, какого-либо заметного влияния на производительность не ощутил (да и не ставил такой цели, если честно)