axdaily: Surrogate keys in AX 2012

[fed]

Цитата:

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

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

Типичный прирост БД на типичном внедрении - гигабайт 20-25 в год. Типичный срок жизни внедренной системы (до перевнедрения на новой версии или замены системы) - 4-5 лет. Значит о террабайтных базах можно не особо напрягаться. Ну будет 100 Гигабайт, может 200. Все что выше - не особо типично. Кстати не следует думать что джойн больших таблиц легко происходит. Вполне возможно что тот же inventTrans за 5 лет в новой структуре будет много hash-joinов использовать, которые и память и процессорное время неплохо отъедают.

Цитата:

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

Кстати по поводу сжатия в SQL 2008 - если не ошибаюсь страницы с индексами он не жмет (в отличие от оракла). Т.е. сжатие не поможет в ускорении работы с индексами. Только сокращение длины ключа.

Жмёт-жмёт. Там есть два способа сжатия.
Первый полезен для таблиц в которых много пустых числовых полей (типа inventSum). Он просто в конкретном экземпляре записи динамически усекает все decimals-поля до минимально разумной длины. В результате время вставки и обновления почти такое же как для несжатых данных, а время чтения лучше процентов на 15-20 (но учитывая что с диска данные редко читаются, выигрыш для конкретных запросов не столь велик).
Второй способ - как раз таки традиционный Run Length Encoding, который в Microsoft FoxpPro использовался с 1989 года То есть - поскольку у нас с индексной странице данные отсортированы, то можно не записывать данные как "Иванов","Иванов","Иванов", "Ивановский", а записать "Иванов", 0x6,0x6,0x6"ский".Правда этот способ сжатия хорошо работает, только если у тебя ключи в индексе отсортированы так, что наиболее уникальные поля- в конце списка. Если у тебя индекс с recId начинается, большой выгоды от такого сжатия не будет. Замечу что такой способ сжатия позволяет сильно (типа процентов на 40-60) сэкономить на времени чтения (с диска), но время записи выростает процентов на 15-20, а нагрузка на проц во время записи - еще сильнее.