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

[mazzy]

Т.е. ты рекомендуешь скорее trans-таблицы.

1.
А стоит ли LedgerBalances*-таблицы?
Обычно они и большие, и содержат числовые данные, и в них много необновляемых чисел за старые периоды...

2.
Насколько стоит геморроится сегментированием таких таблиц, чтобы задать разные режимы сжатия для разных сегментов?

[Vadik]

Цитата:

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

Т.е. ты рекомендуешь скорее trans-таблицы

Перефразирую - большие таблицы

Цитата:

А стоит ли LedgerBalances*-таблицы?
Обычно они и большие, и содержат числовые данные, и в них много необновляемых чисел за старые периоды...

Я пока не встречался с ситуацией, когда остатки по GL представляли собой сколько-нибудь существенную долю от общего объема БД. Сжать - можно (за компанию с транзакционными таблицами), сожмется хорошо (в процентном отношении)

Цитата:

Насколько стоит геморроится сегментированием таких таблиц, чтобы задать разные режимы сжатия для разных сегментов?

Это уже не VARDECIMAL, а DATA_COMPRESSION и соответственно следующая версия СУБД - SQL Server 2008. Стоит ли геморроиться - это уже решать DBA в каждом конкретном случае

[egorych]

Цитата:

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

Т.е. ты рекомендуешь скорее trans-таблицы...

Цитата:

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

Перефразирую - большие таблицы ..

Добавлю мое ИМХО - и еще из которых МНОГО читается. Много не в смысле часто, а много в смысле много записей.
Например у нас INVENTSETTLEMENT у нас ~50млн. Но читается из него по объему не много и в большинстве случаев по индексу - т.е. проблем не доставляет и в top запросов не фигурирует.
А вот SYSDATABASELOG подумываю сжать, ибо как что найти нужно, так IO начинает расти здорово! Ибо интексов ненастроешься на нее!