Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?

[Logger]

***** выделено отсюда Посоветуйте по чистке CustInvoiceTrans *****

Почитал описание
http://technet.microsoft.com/en-us/l...3(SQL.90).aspx
Описан реальный пример при работе с олап кубами в САП

Цитата:

Production Workload SAP BI

SAP BI is the primary workload targeted by vardecimal storage format. To measure the impact on an SQL BI application, we worked with one of our SAP BI customers in Germany to test the impact of vardecimal storage format both in terms of space savings and the impact on the performance of the real-life workload. This customer was very interested in the new storage format to reduce the size of fact tables within SAP BI info cubes that often included a large number of decimal columns. The customer was able to reduce the size of their fact tables up to 80% in some cases without any noticeable impact on the performance of their workload in spite of the extra CPU cycles required to convert decimal data between fixed-length format and vardecimal storage format. This was because the customer's workload was running complex queries involving many joins, aggregates, and other expensive relational operators. These constituted the significant portion of the cost of the query as compared to the cost of scan operators, which pay the additional cost of conversion from vardecimal storage format to fixed-length format. Another way to look at this is that if the 95% CPU cost of your query is in executing relational operators other than scan, even if the CPU cost of scanning goes up by 40%, it is still 2% (that is, 40% of the 5% query cost) of the overall query cost. Here is a summary of the results:

* For the majority of the fact tables, the disk space savings was between 20 and 50%.
* As expected, the space savings were dependent on the table schema (the relative number of decimal and numeric columns), the size of the table, and the data distribution. Thus, for one table that had just one decimal column out of nine total columns, the saving was only 4.76%. Another table, which had 94 decimal columns out of 109 total columns, became 80% smaller in size.
* There were no space savings for indexes because the indexes defined on the SAP BI fact tables did not have any decimal or numeric key columns
* As mentioned earlier, there was no noticeable impact on the query or load performance with vardecimal storage format.

Если я правильно понял данное описание - объем таблиц фактов удалось значительно уменьшить (до 80 % освобожденного места на диске), а производительность при этом не поменялась. (Если неверно перевел - поправьте меня) - я немного разочарован - ожидал что производительность улучшится за счет сокращения объема операций ввода вывода - видимо затраты на распаковку компенсировали выигрыш от сжатия (авторы утверждают что запросы сами по себе были сложные так что время на сканирование таблиц сильно не влияло на скорость выполнения запросов - в общем, по сути, ушли от обсуждения вопроса).

Отсюда вопрос - где эффективнее всего использовать данное сжатие ? OLAP системы ? OLTP системы ?

Если применять к Аксапте, то для каких таблиц ?
Редко обновляемые большие таблицы (строки журналов, заказов, закупок) ?
Часто обновляемые большие таблицы с большим количеством числовых полей (InventSum)?

Аналогичные фичи для оракла кто-нибудь использовал ?